View Single Post
  #9  
Old 11-17-2012, 04:51 PM
schferk schferk is online now
Registered User
 
Join Date: 11-02-2010
Posts: 151
Right!

There are components even for this (as better editors e.g.), that could be integrated in any software. As long as such a components is not only a graphical representation of data, but allows for manipulating the data from this GUI, such an integrated solution would avoid lotsa potential difficulties that might arise by the otherwise necessary balancing of not necessarily convergent interest of two different developing companies - not speaking of the problems arising for the user by concurrent update needs.

Of course, this again shows, as with UR's current editor, that here, the choice of a cheap / free component then produces annoyance for the user, over many years, or, the other way round, prof. sw should incorporate the very best such components. (Formatting within the tree, anyone? = another example of a component (or an original development by kinook?) that's not as good as it should be, at this moment.)

But in fact, quant, your idea would avoid lotsa problems, no clash of two sw corporations and their respective policies "needed" at all here.

I'm more and more inclined to do a second IMS in some years, with top-notch components and with a good programmer doing the coding, if really no current developer will have taken this path until then.

EDIT :

Some minutes ago, I deliberately avoided any comment re TheBrain SDK vs. some more traditional "mind-map" component, in view of my preference to the latter (detailed above), but not wanting to artificially divide a consensus on the means to apply. But of course, these divergences must be treated if a developer wants to satisfy his users.

So, it occured to me that needs and preferences of different users do vary, of course, hence our traditional asking of delivering in-built functions "both" / multiple ways, i.e. to let the USER decide how he wants to do his work, whenever possible, instead of forcing upon him a precise way of doing things which might not please him at all - the apotheosis of such a system being, of course, SAP which every corporation puts into exactly that use that customer has in mind - it's an extreme case, for the asking price as well as for the needed amount (and hence the high price) of necessary adaptation.

So back to components. Let's assume a developer buys a highbrow component for 50 dollar apiece (standard components are rather 300 to 1200 dollar one-time payment), i.e. for every license he sells of his product, he pays 50 dollar to the component vendor (and why not if his price is 250 dollar). Now imagine he'll get TWO such, similar components, one costing him 50 dollar apiece, the other (not necessarily better) one 80 dollar apiece.

Why not offer his sw at a price of 200 dollar without any of these components, at 250 dollar with component one and at 280 or 300 dollar with component two, leaving the choice to his customers?

The additional (!) "man time" for adjustments to not one, but both components might be a week since most of the functionality is very similar - in extreme cases (and I'm speaking of professional coders here) it might be 2 weeks - perhaps it's 4 weeks to integrate one, but 6 weeks to integrate both.

At this price, the developer would make all his users happy, not forcing 50 p.c. of them into a new way of working they only accept for lack of any alternatives; it would propulse his prof. image, it would generate good press coverage, and so on.

The same could be done for other add-ons, add-ins, e.g. those "little corporation" features I spoke of lately: tax-compliant archiving incl. scanning / OCR, mail functionality, and so on: prof. software as a construction kit where users chose the components they want or need. Such a paradigm is way beyond "cheaper crippled versions" and a viable business model.

Meet people's needs, and you'll have happy customers willing to pay your price (as long as it's not beyond reason).

Last edited by schferk; 11-17-2012 at 06:17 PM.
Reply With Quote