Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

The Year Ahead: Predictions for the iSeries Community

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Guest's Avatar
    Guest replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    RD: Thanks for your lengthy comments. I love to read it. Keep it up. PH

    Leave a comment:


  • R.Daugherty
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    Chris, I never referred to anyone comparing 5250 to HTML. No one outside this small world even knows what 5250 is. The comments are on using the browser as interface. The 5250 interface was deemed to be insufficient, sales stopped and programming work along with it, and an HTML replacement "look and feel" of an insufficient interface along with an interactive "tax" would probably explain why the AS400/iseries/i5 no longer sells. But I'll just focus on something else. Thanks for the comments, Chris. rd

    Leave a comment:


  • Guest's Avatar
    Guest replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    Ralph, So, you're saying that a 24 x 80 green screen "look and feel" couldn't be duplicated in a one page HTML document? That's a developer problem, not an HTML problem. One HTML web page can easily hold the equivalent data of one green screen. I'd say the exact opposite is true. Take most any web page out there and it wouldn't fit on one 24x80 green screen. Just look at the MCPressOnline home page. And I still don't understand what you mean by "dumbed down". And do please give us those web links that say 5250 is superior to HTML in reaching a wide audience (customers, end users). Like I've said, the UI doesn't really matter as long as your application architecture can support many UI's. You could give some users green screens and others HTML forms for the exact same business model. Regards, Chris

    Leave a comment:


  • R.Daugherty
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    Well, there was a message from our customers that 5250 wasn't improving to compete with client server. 5250 needs to be improved as I and Dave describe in other posts rather than dumbed down to a browser. The dumbing down includes less information and functionality per screen. Just about every article I've seen on web page ERP rollouts has the customers screaming about taking five web pages to do what they used to on one screen. I saw this with conversion of complex screens to a Java interface in JWalk that I prototyped. The functionality of one green screen had to be broken down to several tabs when GUI'ized. And we all know that if there's a space on a green screen, our users want more info there. That's why our screens are complex, our customers wanted them that way. Again, if browsers were sufficient, then we would running software in browsers, but we don't. But we expect our customers to. It's called eating your own dog food, and we would choke if we had to. rd

    Leave a comment:


  • J.Pluta
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    After I read your post I returned to my desktop and other work, and I realized that all my other work is in Windows programs. This is because you drink the Windows koolaid. In the Unix world, there are a ton of web-based applications, for everything from email to system management. Why? Because you can run a browser almost anywhere. And the world of the midrange is much closer to the Unix world than the Windows world. The Unix world at least makes an attempt to run on sub-gigahertz processors without hundreds of megabytes of dedicated RAM, unlike that standard Windows machine which is now pretty much a gigabyte and 2.5GHz. Joe

    Leave a comment:


  • J.Pluta
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    It's not my opinion, it's the opinion prominently noted elsewhere in IT publications. I rarely care what IT pundits say. Even so, I don't know of a single IT publication that insists that the browser is a bad interface. Feel free to get those URLs out. Most of those folks lost their credibility as they parroted the ITAA as they told us there's a shortage of programmers in the US. Anyway, back to the question, which is pretty simple: what does 5250 do that HTML does not do? Since 5250 is arguably the most successful UI ever created, and still going strong, and it is the overwhelming interface for our market, it seems clear to me that the next generation UI needs in our market needs to be functionally equivalent to 5250, and thus the question arises: how is 5250 better than HTML? Both Swing and RCP are thick clients; RCP simply makes better use of native components, although at the price of being tied more tightly to the OS. But thick clients are almost useless in the era of Internet access, for any number of reasons (not the least of which is distribution). Someone may eventually come up with a zero-footprint thick client (and in fact there are a few projects like that in place). At that point we may have a thick client option, but until then the thick client is not a solution for my customers. According to my customers, zero-footprint browser access is absolutely necessary, and not one of them agrees with your assessment of HTML. What they do agree on is that there is a certain class of power user who requires host-centric applications to be tightly tied to desktop programs, and those particular users can use a thick client. But my users do not see replacing green screens with thick clients; they majority of green screens will be replaced by browsers. Joe

    Leave a comment:


  • R.Daugherty
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    A couple of more things. I notice you mentioned the interactive tax again. The first time I read it I thought you were referring to green screen to GUI conversion overhead, but then it dawned on you're referring to IBM and their "tax" on interactive processing, commonly referred to as green screens. For that alone no one who knows this should do business with IBM, and they aren't. After I read your post I returned to my desktop and other work, and I realized that all my other work is in Windows programs. No software development company besides ERP's, CRM's, and the like produces screens with a browser. And you ask what is wrong with a browser. I ask you what is wrong with every software development company in the world besides IBM and Oracle. I guess they don't have IBM's genius in understanding that a browser is what all of our software should be displayed in. And if not them, why us? rd

    Leave a comment:


  • R.Daugherty
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    Hi Joe, It's not my opinion, it's the opinion prominently noted elsewhere in IT publications. I could quote all day but the conclusion from those who analyze this is that the browser doesn't cut it. Efforts are under way to find some set of technologies to go to that will cut it. Those technologies will require use of the native desktop GUI. IBM also acknowledged this in a way when they went to Rich Client Platform away from Sun's standard of platform independent Swing, which is far more capable than HTML rendering in a browser. IBM's choice for Eclipse makes use of the native platform GUI. Their interface for the AS/400 should do the same. rd

    Leave a comment:


  • R.Daugherty
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    I should add that the advanced GUI conversion programs like MorphMaster rendered to a Windows program, not a browser, and the program didn't have the overhead of the browser toolbars and still went into scrolling as they tried to render complex green screens into GUI. Rendering to a browser is even worse. rd

    Leave a comment:


  • J.Pluta
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    Ralph, what specifically do you think HTML cannot do? It seems to me you're concentrating on some pretty crappy products. PSC/400 creates a UI that supports nearly all of the basic 5250 features, looks good, runs fast and requires no interactive tax. So what's missing? Joe

    Leave a comment:


  • R.Daugherty
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    Dave, I have seen your excellent analysis of 5250 emulator capabilities through the years, and had that at the top of my mind when replying to your post. Concerning the question of working with BOS Morphmaster, I had the honor of prototyping some solutions back in 1998 with Izzy Gal and his team for a very large company where I was the AS/400 R&D Team Leader. I took a look at many products. I will have to say that as good as BOS is, complex green screens just were too much for a browser space, especially since that space is reduced even further by browser overhead unless taken away with F11 Full screen or equivalent. MorphMaster took one entirely different tack, that of on the fly rendering with no footprint of templates required, no screen conversions. The BOS coders are really good, and just from our protoyping feedback I saw improvements come down the pike in their product. You can't ask more from a vendor. Tne problem, which is ironic since you noted it is an advantage, is that the rendering of a complex screen with even small GUI borders is that it shoves the bottom of the screen out of sight. What some call flexibility I call loss of usefulness, the inability to see the bottom, the requirement to pull the screen up to use the bottom which often contained function key buttons or even data, and overall slowing down the user. We have discussed this here before, and some think the answer is a 1280x1024 screen. I think the answer is a native GUI base with pre-engineered complex and solidly performing screens which by the way are also now anchored in the desktop world for user control of interaction and integration, things that we need to make available and deal with in our apps in a general way, not knowing specifically what is going to be connected to what to send and receive data. We need to be an enabler and conduit of smart business use, not a generator of dumb web pages and flat files to copy into that desktop world where people finally can use their as hoc smarts to get their job done. My personal opinion is that an open source Java canvas rendering program with smarts for talking to other desktop apps through JNI to Windows COM, other JNI, sockets, and a plug in for any other kind of connectivity one may desire is the way to go. The communication with the AS/400 would replace 5250 streams with XML streams, and at that point you could have machine to machine interaction between apps, much as we do today with 5250 emulation with devices. The pettiness of what a browser can do is also performed by a Java canvas program that is essentially a superset of a 5250 emulator, and performed within the screen. HTML rendering may be be ubiquitous, but it wasn't designed to provide screen engineering. It is being misused by a software industry that is looking for cheap and easy when engineering is what we are supposed to be able to provide. The people who provide that quality engineering will get the business. rd

    Leave a comment:


  • R.Daugherty
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    Chris, ubiquitous UI of the world for Google such as I use it is not the same as ubiquitous UI to replace the functions of thousands upon thousands of complex business transaction screens that we and ERP developers of other platforms have created over the years. Software people keep saying what you are saying, and users are saying go take a hike. They will go with a solid GUI program every time, even a green screen emulator for many functions, no matter how easy and convenient it is for IBM to say the browser is ubiquitous. You see it in every comment when dumbed down browser screens are shoved down people's throats that greatly hurts their productivity. They rebel, as they should. Software people are trying to make it easy for themselves, and they deserve to lose when they do. rd

    Leave a comment:


  • Guest's Avatar
    Guest replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    Ralph, Whether people like it or not, HTML is the ubiquitous UI of the world and that's not going away anytime soon. If IBM tried to create their own UI for the world, it would be declared as proprietary and fail of course. What's important is that we developers use better architecture in our applications (MVC) so that the UI can be swapped out if something better does come along someday. Yes, that includes green screen. The business logic programs should never have an F-Spec WORKSTN defined in them (the "model"). Chris

    Leave a comment:


  • David Abramowitz
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    Ralph Dougherty wrote: I think the first thing we all must understand and acknowledge is that the browser interface is a weak substitute for the full 5250 green screen interface with mouse, menuing, and window support If that's the case (and I'm not saying that it is), then what is needed is enhanced 5250 and telnet support. IBM already provides this capability with an add-on product, and there are many other good emulators that go a bit beyond screen scraping. (Has anyone worked with BOS morph master?). The first thing would be to make basic enhancements to the 5250 interface. I have been advocating this for years. I think that it can be done, and can be done easily without disrupting existing code. We already have pull-downs, radio buttons, and check boxes (SNGCHC & MLTCHC keywords). Here are some other 5250 possibilities:
      [*]More colors[*]Font and Font size choices with mixed font capability on the same screen.[*]Menu bar positioning.[*]Multiple fields within SFLSNGCHC , and SFLMLTCHC subfiles.[*]The ability to create a mouse button out of anything.[*]Graphic Window recall (This was actually possible with the Ultimedia product, but so hard to use that no one bothered).[/list]There's probably a whole lot more. If anyone thinks that this is just a wish list, I might remind them of the 5292-2 terminal that had these capabilities and more. You could actually draw crude graphics on the 5292-2 within the realm of 5250. To this day there are APIs that can give you more colors. There are many text based telnet terminals that allow different typestyles and sizes. These can make for a very effective presentation. The argument against such development is the page. Within terminal emulation you are limited to a maximimum fixed size screen. While screens using the WINDOWS keyword can be most any size, they must conform to the rules of the character, and cannot appear above or below the 27x132 maximum. Browser development need not have such limitations. As much as I hate to admit it, the browser can have greater flexibility. Dave

    Leave a comment:


  • R.Daugherty
    replied
    The Year Ahead: Predictions for the iSeries Community

    ** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
    An interesting challenge to Toronto, Dave. I think the first thing we all must understand and acknowledge is that the browser interface is a weak substitute for the full 5250 green screen interface with mouse, menuing, and window support. After all, that was a Windows program, and it could take advantage of a real GUI interface to map our business solutions. I have chellenged the premise of a browser as suitable ubiquitous interface from the beginning, and each passing day only confirms that the browser as interface is wrong and a failure. One only has to read outide the IBM world to know this. It is an utter failure, but IBM has dropped us into the big blue with it tied to our hands and we are going down with it. Everyone else knows this. Microsoft added mini Windows capabilities into its Windows browser and every app of any complexity required those capabilities. We saw this in the IE 5+ required for e-commerce websites, and that was just for consumers. We are not even talking about business users trying to complete complex business transactions there, and it was insufficient without using Windows. It is clear that the solution to map terminal screens to a browser is there only because it is easy. Easy doesn't cut it to win business. Given that the browser has no more capabilities than full Windows 5250 emulation, the current DDS keyword set should already be sufficient or close to what is needed for generating user interface independent screens, such as 5250 green screens, the browser, and richer client interfaces such as Java, Windows, and KDE. Additional keywords would help richer interfaces do more work, but wouldn't be required. The key is not how pretty the interface is, the key is integration. One of the ironies of our failed experiment is that the browser provides less integration that even a Windows 5250 emulation program. At least it was a Windows program, and thus the designers could build in integration with the outside world with it. But that world was Windows, the world of our business users, the world where people perform their work, the world that chooses what to buy and what interface to work with. It is the lowest common denominator mentality of IBM that brought us to this point, a world where the lowest powered display and the lowest powered database access is their choice because it is easy and runs anywhere. Our business users don't have anywhere, they have somewhere, and that somewhere is Windows, and they will buy the most powerful solutions provided for their somewhere. We have to provide that powerful solution, and it requires a user interface that integrates with the rest of the world, be it Windows COM, Java JNI, Linux KDE/Gnome, Unix X-Windows, sockets, and even other 5250 sessions open on our interface. Integration is what people are looking for, not a pretty display. We are not providing either. Whoever does will win, and for my career I hope we at least stay in the game. rd

    Leave a comment:

Working...
X