Andrew N. Shrosbree wrote: > Tim, > > Contributions to this list about how we can improve Argus are always > appreciated > by ArgusConnect. Many suggestions made here has provided the impetus for > changes > to our product, and in some cases we have reviewed our policies and > strategies > in response to feedback from users like you. > > Syan Tan's implementation of non-HeSA libraries some time back paved the way > for > our adoption in 2007 of BouncyCastle PKI. Argus is hence no longer in any way > tied to HeSA PKI. This has been an excellent move.
OK, sorry, I wasn't sure if the HeSA PKI stuuf had been replaced by BouncyCastle yet - glad that it has - this makes Argus much more useful to us for public health lab reporting purposes. > Similarly, despite our > initial reticence about PGP (which was based on our concerns about the > 'trust' > management issue), we are now looking at the possibility of PGP-enabling > Argus > while we are implementing our new web-service product. Our attitudes to both > PGP > and web services have been strongly influenced by outsider's input, both from > our users and from standards authorities like NEHTA. OK. > If you regard our attempts to shield users from the complexity of our HQL > scripting language as paternalistic, I must apologise and offer a mitigating > rationale. We have learned painful lessons time and time again when we have > not > shielded users from complexity. In the case of HQL, for instance, we hope > eventually to provide a very high-level interface for HL7 data extraction > that > would completely hide the implementation. We in no way intend to 'hide' any > technical capabilities from those who wish to delve into more complex > management > of the product, but the facts are that the average user just doesn't wish to > know this. We are more than willing to assist those who wish to have access > to > the more technical processes get access to them. We will continue to try to > cater for both demands. The trick is to make access to the complexity optional. Providing documentation for your HQL transformation language doesn't force end users to use it, but not providing documentation makes cluey users, including corporate users, look wistfully at other products that do offer documented "power user" customisation features. > One of the consequences of the openness and freedom of choice we try to offer > the messaging community is that we have unwittingly given our competitors a > huge > stick with which to beat us: they point out how complex Argus can be to > install > in comparison to other products. Naturally, in our desire for user acceptance > it > serves us well to minimise that complexity. We do realise that it is possible > to > provide a 'dumbed-down' user interface and still allow techos to get deeper > into > the product, but because our (limited) resources have been focused on making > Argus as user-friendly and easy to support as possible, we have de-emphasised > the ability to 'get down and get dirty' with the product. Sure, but none of that is an excuse for not wanting to document your message transformation language. If you just said "We haven't had time to document it." then that's OK, but your apparent reluctance to document the transform language lest users use it to do damage is a bit paternalistic I feel. But it is a common attitude, and one I can understand, having been very tempted to adopt similar attitudes myself at times. However, the trick, as I said, is to make high level, complex features optional - don't force users to write HQL code, but if they wish to, give them the tools to do so. > We will always embrace a collaborative relationship with the Australian > market, > and I wish personally to reassure everyone that we are always listening. Yup. As I said, I think your product is the second best open source HL7 messaging engine in the whole world, and the best supported open source HL7 messaging engine in Oz. Tim C > Tim Churches wrote: >> Andrew N. Shrosbree wrote: >> >>> That's why I suggest that a comparison of Mirth with Argus would be >>> enlightening, because Mirth's makers are not quite so paternalistic in >>> their approach to end users, and they encourage end users to develop >>> message transformation scripts and make them available to the wider >>> Mirth community. >>> Tim C >>> > -- > -------------------------------------------------------------------------------- > Andrew N. Shrosbree /B.Sc,B.Ec/ > Technical Architect > ArgusConnect Pty Ltd > *Phone: *+61 (0)3 5335 2214 > *Mobile: *+61 (0)415 645 291 > *Web : *http://www.argusconnect.com.au > *Email : *andrew.s at argusconnect dot com dot au > <mailto:[EMAIL PROTECTED]> > > My status...just call me <skype:andrewshroz?call> > > View my Skype profile (andrewshroz) <skype:andrewshroz?userinfo> > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
