Tony (and Sean), I can't let this "challenge" go unanswered, and whilst I know you don't want to get into a feature for feature slugging match ..... sorry folks, please switch channels now, cause this could be a long one (and I also appreciate that there are other products in this space as well)
I've embedded comments : >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:owner-u2- >[EMAIL PROTECTED] On Behalf Of Tony Gravagno >Sent: Wednesday, 8 September 2004 8:37 AM >To: [EMAIL PROTECTED] >Subject: RE: [U2] Southern California presentation on DesignBais > >Sean W Ferguson wrote: >> Interesting product. How does it compare to Visage? From a quick >> glance at the DesignBais website they look very similar in concept and >> design. >> http://www.staminasoftware.com/Products/Visage/Products_Visage.htm > [Ross Ferris] Sean, Whilst on the surface the products appear to provide a similar end result, and certainly the "concept" that I believe has driven the design of both products is the same (GUI using thin client technology with a zero deployment footprint beyond a standard Windows install), under the hood they are completely different. My understanding is that DesignBAIS (DB) has been developed using ASP technology (circa 1997 when Microsoft shipped Active Server Pages with IIS 3.0, not to be confused with the later/latest ASPX technology which is part of the Microsoft .NET strategy) We considered this path ourselves, but we found what we considered to be "serious" problems with it, some of which may not become obvious until a system is under load. For example, as the name (ASP) "nearly" suggests, pages are created "on the fly" on the server using script and COM objects, but this dynamic nature means that the page itself can't be cached by the client and so has to be sent out EVERY TIME a page is requested. Whilst you may not notice this impost over a high speed LAN, if you DO deploy over the Internet you may start to see "stutter" quite early in the piece, simply because a page that you have already referenced a hundred times today may need to be sent down the line yet again ! The ASP model also maintains "state" (sort of like "where a traditional program is up to", variable assignments etc) within the ASP core on a single machine, which means in a web farm situation requests for a particular "session" (roughly a PIB or user in UV terms) have to be routed via the same machine, even if it is under extreme load. Once more, this may not manifest itself at the smaller end of town, but we didn't want to start out making compromises :-) As a result, Visage uses static web pages (which ARE cached on the client to improve speed, only the data that will populate a page with information has to be sent, and even then we have techniques to avoid this if we don't have to), and state isn't reliant on a web server (you could reboot, or loose, a web server in a large Visage array/web farm without missing a beat) We also saw issues with debugging, speed of script interpretation on the server, the complexity of the processing model, and many others, and I believe that these same concerns have fuelled Microsoft's development of ASPX as their next generation solution. (DEEP under the hood the differences in the products can have a more significant and profound impact. ASP/DB will only ever generate HTML, but with Visage we actually generate HTML from the XML definitions created with the Visage.Designer - our Version 7 product to be released later this year lays the foundation for generating XAML (eXtensible Application Markup Language), which is the core of the Avalon display technology that will surface with the "Longhorn" project from Microsoft in 2006(?). There is some other "interesting" stuff in terms of "fatter" clients (Java & .NET/Mono), web services etc, and some other "interesting" concepts that we still have under wraps in the pipeline) You are right when you say the products yield a similar result, and for the majority of people that is probably enough. >I have no experience with Visage yet, outside of presentations at various >Spectrum shows, but from what I've seen it's more "complex" than >DesignBais. >I distinguish between features and complexity. In my mind, DesignBais will >appeal to a wider variety of Pick developers because it does not expose >them >to HTML, scripting, components, etc.. It has a lot of features but it's >simple for Pick developers to get at them. [Ross Ferris] I have no experience with DB, so on that score we are "even", BUT I've snipped the following from an email I received last month from someone that HAS done the comparison, and he said (in part) : >>DesignBais is simpler & so is more intuitive - but will >>require more work to set up a system. >>I got the impression that you are more committed to the >>product than the DesignBais people. This may or may not >>be correct, but Visage felt a lot more developed and a lot >>more solid. The Windows integration seemed more sophisticated. >> >>All in all, yours seemed a better product At the end of the day though, neither of us had a win because ... >>I'll tweak my 4GL a bit more (using more of the HostAccess >>gui features) and I'll have a look at Visage & DesignBais >>again in a year or 2. To suggest that Visage exposes developers to HTML, or requires an intimate knowledge of scripting is simply not true. Indeed in my presentations I usually make a big point about the fact that the ONLY line of script someone MAY need is : VRE.doAction("callMV") And I don't mind if people copy this massive script :-) On the component side, YES, we do let people drag & drop components onto a form. These can be ActiveX components to, say, add a graph to a page, or a tree control, or maybe even a scanning component if people want to use image capture facilities - I believe these are good things ! Of course we also let people build and design their own "components", which are sort of like a "visual subroutine". If you are capturing the same information in many places, say starting & ending dates and a range of customers for various reports, you can simply design this once, then re-use this component over & over again. You don't HAVE to use this feature, but most people who have seen it in action LIKE the idea of being able to add functionality in one place and have it just "happen" throughout the system - just like adding functionality to a subroutine in Basic :-) and the only "complexity" is that you flag your design as a component !?? Visage is very big on "re-use" - from dictionary items & existing logic, through to screen fragments (components) and entire processes (collections of discrete screens) Whilst I agree that a feature-by-feature, blow-by-blow comparison does little (and I think we both know who would "win" :-), there is at least one feature that people should consider. Visage will happily co-exit with your existing green screen systems because it exerts (and honours) "traditional" READU locks, out of the box! AFAIK DB does not. Whilst I can understand why you might want to "sidestep" a feature like this, it IS important for people to know about this limitation on the way in, don't you agree ? (and for those interested, we can also do optimistic locking - indeed, you get a file-by-file choice !) I also think that it may be important for people to understand WHY we refer to Visage as an Application Development Framework, rather than just an Integrated Design Environment (IDE) like DB. Visage is a layered product. The full Visage family includes : * runtime engine/environment * screen designer * report designer * client report viewer/engine * server based reporting engine * business intelligence/analytics/data warehouse designer (BIT) * server ETL engine (BIT "cube builder") * client BIT viewer * standalone BIT viewer * remote monitoring server (a MUST in a 24x7 environment) * server forms processor using Word as the engine * server Email Gateway * server Fax Gateway With more facilities on the way (eg: Server Web Service gateway that allows you to "publish" a pick basic subroutine as a web service, "PUSH" upgrade server to enable automatic updates at client sites, along similar lines to the Windows Update service) Last time I looked, DB dropped out around point 3 or 4 (reports at the time appeared to simply be "tables") - and that's before we look at the "features" and capabilities within these offerings People can use as much, or as little, of the Visage product stack as they need. For example, we have people who have only installed the Business Intelligence component (Visage.BIT), or the Email gateway as a means of syncing distributed databases. Whilst you can buy third party products to add some of this functionality "any" product, there is something to be said for having a common look & feel. If people want to add an OLAP cube to their Visage applications, it is just another "component". I don't see the use of building an application that lacks these facilities - BUT you don't have to use them ! OR you can grow into them over time. (Interestingly enough I think that Microsoft agrees, as Visual Studio 2005 will have some form of BI capabilities built in - and I think it is "cool" that I can do this with a multi-value tool today !) In terms of 'complexity', most "Pick" people that I've talked to seem to be able to access the features just fine, and have their first GUI screen out in under an hour - and that includes creating files & dictionaries using the GUI admin facilities! On the other side of the coin, we have had Windows & Java developers use Visage to develop systems without any knowledge of "pick", and armed with a dictionary my experience has been that most clerical staff can handle the drag'n'drop metaphor just fine to develop their own screens :-) > >The pricing model is also very attractive for sites that want to get up and >going quickly. $1000US for a developer license and end-user seats are $100 >per year for license and support. This is very attractive for small >end-user sites as well as large ASP service offerings or other WAN >deployment. Over a period of years you might find Visage competitive in >this area, but these days who knows how many sites or users we're going to >have over a period of years? [Ross Ferris] Tony, you keep throwing this out as a big "advantage", and I keep telling you that this isn't the case, so hopefully I'll now set the record straight in a public forum. Visage offers multiple pricing models, because we have found that in this regard one size DOESN'T fit all. To make a direct comparison with the pricing you have offered for DB you would look at our Annual Subscription Licence - you even save a $1/seat ! You can make even "bigger" savings on the Designer ($5) Many companies are uncomfortable with this open ended, "pay forever and hope they are here next year" arrangement, and want the "comfort" of a real/perpetual licence with the OPTION of maintenance. This piece of mind costs just $200/seat - so the break even point would be just over 12 months --> we have VARS with "old" 6.08 versions in place from 3 years ago, so they would appear to be $100 in front - and counting ! Even with a full maintenance contract in place the break even point is just 3 years, and every year after that, ASSUMING YOU CONTINUE WITH MAINTENANCE, you save $50/seat/year over the subscription pricing model. AND, because for some environments the whole notion of "per seat" just doesn't hold water (how many "seats" do you need for an E-commerce site?) we also offer a PORTAL licence, that doesn't impose ANY seat limitations (we have other mechanisms, typically limiting the number of connections to the database to "throttle" performance. The Portal licence is also available as a "one off" (fixed/known) licence, or on a subscription basis On the basis of these FACTS, could I respectfully suggest that not only is Visage "competitive" (read CHEAPER!) in terms of pricing in the long AND short term, it offers significantly better value for the money ! > >DesignBais was also written by a company who has an insurance package >written in SB+, and there are strong similarities between SB+ and >DesignBais. There are some basic tools in the package for helping with >migration from SB+ (should anyone wish to do so), or integration with it >for >_adding_ a web browser interface. This is a strong selling point that >seems >to appeal to a lot of SB+ VARs. [Ross Ferris] Well, you got me there ! We didn't use SB/SB+ as our reference point and yardstick. Rather than limiting ourselves to the Pick market, we looked for idea's in the broader "mainstream" community - which of course explains in part why developers from the "outside" feel right at home with Visage :-) We also have people that have converted applications written in SB+, and also a variety of other "homegrown" and/or proprietary 4GL's, and even "straight" Basic. It's getting late, so I won't launch into a dissertation of how Visage automatically supports a cascading object hierarchy, or our data abstraction layer, or even our Active Code Reduction program and the productivity increases that our recursive/extensible/optimising pre-compiler can bring about. Visage doesn't pretend to be an SB+ clone - we will support people who think that references to OTHER.REC<1,2> (or o1.2) is a good way to move forward, but we can also offer a 21st Century solution rather than a 1980's remake:-) <snipped the ad> > The tactical approach (tools) is far less important than the overall > strategy of making an application more attractive to help it sell. > [Ross Ferris] By now it shouldn't come as too much of a surprise that I disagree on this point as well - I think the tool selection IS an important aspect of an overall "go forward" strategy. We all know that "getting there" is one thing, but it is the ongoing maintenance cycle that the majority of "developers" are ultimately involved with that represents the lions share of the "real" cost of an application. It is this recognition that is driving our efforts in many areas, including "unimportant" (by implication) issues like automatic upgrade distribution, because this will save you time AND money, improve your service levels and (if you are a VAR) potentially give you an "edge" over the competition. This is also why Visage is like a Swiss Army Knife - by offering a single toolset that DOES (try to) do EVERYTHING, learning curves are reduced, integration issues simply don't exist, and you can concentrate on just making your applications "more attractive" today if that is your initial goal, safe in the knowledge that you can easily add those extra features tomorrow when they become mandatory. Can you imagine investing months or years in "window dressing", only to discover that you have hit a brick wall ? Talk about square pegs, round holes, and good money after bad !!! Tony, I think the tool IS the single most important decision you can make in this situation. Everything you do (or don't do) after selecting the tool is impacted by the capabilities of the tool itself. Metaphorically, this is why I use a hammer to drive in nails, not a screw driver, but sometimes I want the speed & convenience of a nail gun - and also the option of using a screw, and maybe even glue if that makes sense. Having the right tool for the job at hand makes IT easier. I would like to think that this is why major software developers like Reynolds & Reynolds have adopted Visage, and why other companies have "thrown away" years of Java development when they moved to Visage, and haven't looked back. Visage is a "little" more than just a "veneer" to make an application more attractive (refer Application Development Framework :-), so perhaps can take a greater role in your "overall strategy". I'm not sure if I'll be able to get this point across in an hour or 2, after you have spent months with a "tool" like DB, but I can try :-) Good luck with the presentation ! --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.754 / Virus Database: 504 - Release Date: 6/09/2004 ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
