home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 8 Other / 08-Other.zip / week_2.zip / Framing.txt < prev    next >
Text File  |  1996-01-08  |  30KB  |  583 lines
  1.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  2.  To:    Jon Duringer[IdeaFa, 71732,3361    Monday, January 01, 1996 3:24:05 AM
  3.  From:    Samuel G. Little, 70544,10    #69845
  4.  
  5.  > ...Moore's message to me is, "Jon, at the end of January all OS/2
  6.  > users will be distributed among Moore's categories with respect to
  7.  > desktop calendars."
  8.  
  9. That's a way of looking at Moore that I hadn't considered in any depth. Unfortunately, if the market is 
  10. as transient as the product (or its marketing strategy), it makes 'hitting' the target market that much 
  11. more difficult (although no sane marketeer hopes to capture an entire market). Thanks for the 
  12. perspective!
  13.  
  14.   --Sam. (Warped & using GCP 2.22)
  15.     sam_little@iacnet.com
  16.  
  17.  
  18.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  19.  To:    Samuel G. Little, 70544,10    Monday, January 01, 1996 10:48:14 AM
  20.  From:    Jon Duringer[IdeaFa, 71732,3361    #69863
  21.  
  22. >> if the market is as transient as the product
  23.  
  24. IMO it is -more- transient, in the sense that individuals are constantly moving from one category to 
  25. another, driven by personal circumstances as ephemeral as their mood or state of health.  Today, 
  26. Joe User can be a "laggard" with respect to (w.r.t.) desktop calendars yet simultaneously be an 
  27. "innovator" w.r.t. database managers.  Next week, after Joe commits to using a particular database 
  28. manager for the project that he's just begun, he might be the ultimate "laggard" w.r.t. database 
  29. managers, in the sense that he is completely uninterested in any news regarding that product 
  30. category.
  31.  
  32. IOW, the category that Joe User falls into depends on the product category, and for any given 
  33. product category, is ephemeral.
  34.  
  35.  
  36. >> makes 'hitting' the target market that much more difficult
  37.  
  38. I don't see why.  The only implication of the above is that the names of the individuals change.  Let's 
  39. say that you have a desktop calendar that is discontinuous enough that you've decided to market it, 
  40. initially, to the "innovators".  Now, let's say that you are deciding whether to launch at the end of 
  41. January or at the end of February.  The only implication of the above is that many of the "innovators" 
  42. in the market for calendars at the end of January will no longer be "innovators" at the end of 
  43. February, and that they will be replaced by new arrivals in that category in February.
  44.  
  45. The effect on concluding the sales cycle successfully with any one prospect is more significant.  If 
  46. people move from one category to another, ephemerally, that means that you need to close the sale 
  47. quickly.  For example, if you're market communication is based on the assumption that your 
  48. prospects are innovators, you'd better close the sale before those individuals flit away into another 
  49. category.  IOW, "I'm interested today, but I might not be tomorrow!".
  50.  
  51.  
  52. >> Thanks for the perspective!
  53.  
  54. And thank you, Sam, for this stimulating conversation.
  55.  
  56.  
  57.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  58.  To:    Jon Duringer[IdeaFa, 71732,3361    Monday, January 01, 1996 10:31:14 PM
  59.  From:    Samuel G. Little, 70544,10    #69900
  60.  
  61.  > Today, Joe User can be a "laggard" with respect to (w.r.t.)
  62.  > desktop calendars yet simultaneously be an "innovator" w.r.t.
  63.  > database managers.  Next week, after Joe commits to using a
  64.  > particular database manager for the project that he's just begun,
  65.  > he might be the ultimate "laggard" w.r.t. database managers, in
  66.  > the sense that he is completely uninterested in any news regarding
  67.  > that product category.
  68.  
  69. Funny, but reading this, one wonders (well, "I wonder" <g>) how "office suites" could be as successful 
  70. as they have been....
  71.  
  72.  > >> makes 'hitting' the target market that much more difficult
  73.  >
  74.  > I don't see why.
  75.  
  76. Moore's implication is that separate marketing approaches are required for the innovators, early 
  77. adopters, etc. Simply put, a product cannot be bleeding-edge, cutting-edge, and 
  78. established-technology all at the same time. As one moves farther along the bell-curve, the product 
  79. starts to lose the appeal of its previous market, as they move to newer technologies (and there will 
  80. always be newer technologies).
  81.  
  82. This makes timing absolutely critical.
  83.  
  84.  > The only implication of the above is that many of the "innovators"
  85.  > in the market for calendars at the end of January will no longer
  86.  > be "innovators" at the end of February, and that they will be
  87.  > replaced by new arrivals in that category in February.
  88.  
  89. Early in the process, I agree. The problem is once you move on to early adopters or early majority. I 
  90. tend to move the opposite direction in some technologies, for instance (e.g., the current offerings 
  91. don't meet my needs, so I have to move to less well-established products). This often works even if 
  92. the newer products don't meet my criteria either as I may be able to influence futher development of 
  93. that product -- for instance, I got Markus Schmidt to make a minor change in ZOC which made the 
  94. product ideal for my circumstances. I wouldn't expect the same from Hilgraeve, and certainly not as 
  95. quickly as it happened!
  96.  
  97. So ships may pass in the night, so to speak <g>.
  98.  
  99.  > If people move from one category to another, ephemerally, that
  100.  > means that you need to close the sale quickly.
  101.  
  102. Agreed.
  103.  
  104.  > And thank you, Sam, for this stimulating conversation.
  105.  
  106. Well, as I've found it difficult to "do the homework" wrt specific questions about the product and its 
  107. marketing stragegy (as there is none), keeping the discussion going seems my best bet....
  108.  
  109.   --Sam. (Warped & using GCP 2.22)
  110.     sam_little@iacnet.com
  111.  
  112.  
  113.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  114.  To:    Samuel G. Little, 70544,10    Tuesday, January 02, 1996 11:03:25 AM
  115.  From:    Jon Duringer[IdeaFa, 71732,3361    #69932
  116.  
  117. >> how "office suites" could be as successful as they have been....
  118.  
  119. Bundling might be an effective general strategy for marketing to the late majority, i.e. to people who 
  120. don't care a whit about the difference in capabilities between the spreadsheet that is bundled and 
  121. the spreadsheet that is currently the latest and greatest.
  122.  
  123. I didn't mean to say that everyone is always bouncing from category to category.  Network 
  124. administrators, in terms of the dollar value of their PO's, are probably forced to take their positions in 
  125. the late majority, regardless of their -personal- work styles.  I.e. they might have the latest and 
  126. greatest on their -own- machine, but that doesn't reflect how they spend money on the 1000 node 
  127. network.
  128.  
  129.  
  130. >> separate marketing approaches are required for the innovators, early adopters, etc.
  131.  
  132. Yes, I don't see why the movement of individuals from category to category makes marketing 
  133. difficult.  It complicates the -sales- relationship with the individual prospect, but it does not affect one's 
  134. marketing program.  First, you implement a marketing program designed to appeal to, and meet the 
  135. expectations of, innovators.  You might run this program for 12 months.  Over that 12 month period, 
  136. individuals move in and out of the "innovator" population, but so what?   For the next 12 months, you 
  137. implement a new program that targets "early adopters".  Again, during that 12 month period, 
  138. individuals move in an out of the "early adopter" population.  Your sales manager will care about 
  139. this, but your marketing manager will not.
  140.  
  141.  
  142. >> This makes timing absolutely critical.
  143.  
  144. In business, getting it 80% right is often good enough.  IMO, realizing that you need to market to 
  145. innovators first, then you need to transition to a marketing program aimed at early adopters, is 80% 
  146. of the game.  I think that if you are thinking and acting along those lines, and you are aware of the 
  147. pulse of your sales relationships, then the timing issue will take care of itself.  You can't finesse this 
  148. too much; it's more like "driving" an elephant than a sports car.
  149.  
  150.  
  151. >> I got Markus Schmidt to make a minor change in ZOC which made the product ideal for my 
  152. circumstances.
  153.  
  154. Markus is a great example of why OS/2 users should take a serious look at the products in GO 
  155. OS2SHARE periodically.
  156.  
  157.  
  158. >> I've found it difficult to "do the homework"... [without having a] product
  159.  
  160. Sam, I invite you and others who have not yet released a product to adopt "how to launch a 
  161. meterware community" as your foster child marketing problem.  Anyone interested can post 
  162. questions about meterware in the "Shareware Issues" section of GO OS2SHARE.  That way, we can 
  163. discuss meterware over there and keep this forum focused on Moore's book.
  164.  
  165. We can call it the Meterware Launch Team.  We can discuss the Moore book here, and then go over 
  166. to OS2SHARE and get to work on how to -apply- Moore's ideas to launch a meterware community.
  167.  
  168.  
  169.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  170.  To:    Jon Duringer[IdeaFa, 71732,3361    Wednesday, January 03, 1996 3:53:04 AM
  171.  From:    Samuel G. Little, 70544,10    #70038
  172.  
  173.  > Bundling might be an effective general strategy for marketing to
  174.  > the late majority
  175.  
  176. Something else I've failed to consider ... you've done it again!
  177.  
  178.  > I didn't mean to say that everyone is always bouncing from
  179.  > category to category.
  180.  
  181. I don't think you did say that, either <g>. There are probably all possible combinations out there 
  182. somewhere....
  183.  
  184.  > Yes, I don't see why the movement of individuals from category to
  185.  > category makes marketing difficult.  It complicates the -sales-
  186.  > relationship with the individual prospect, but it does not affect
  187.  > one's marketing program.
  188.  
  189. I was thinking somewhat about apps that "fuse" disparate product elements ... things that are 
  190. innovative in some way, yet conservative in others. Banking or professional accounting systems, for 
  191. instance (thinking of that article in OS/2 Mag <g>), where the interface is truely innovative (compared 
  192. to other interfaces out there), yet the principle underlying transaction are more-or-less the same ones 
  193. any such system would do.
  194.  
  195. While the above is a fairly simple two-item situation (foreground and background), some packages 
  196. may have many subsystems fitting into a whole range from the innovative to the now-mundane. Is 
  197. such a system more or less difficult to market? Is it more or less likely to appeal to innovators, early 
  198. adopters or the majority? Do I need to read ahead in the book (or beyond the first 5 pages of Chap. 
  199. 3)?
  200.  
  201. I have the natural tendency to attempt to consider possible breaking points early on in any 
  202. systematic analysis of a problem because it provides the basis for what (I think) are better questions 
  203. to get answered. So don't take my negativity as pessimism or criticism; it's just my way of working out 
  204. what perhaps requires further thought.
  205.  
  206.  > I think that if you are thinking and acting along those lines, and
  207.  > you are aware of the pulse of your sales relationships, then the
  208.  > timing issue will take care of itself.
  209.  
  210. Yes, I would think that recognition of the "then there is no market" part of the process is crucial. 
  211. Otherwise one would be like a squirrel who hasn't prepared for winter.
  212.  
  213.  > I invite you and others who have not yet released a product to
  214.  > adopt "how to launch a meterware community" as your foster child
  215.  > marketing problem.
  216.  
  217. Of course, you realise that the problem with attempting to do such a think is that I know very little 
  218. about the product or its market. It would make more sense for me to use Cognito! (which, at least, is 
  219. usable under OS/2) and/or IAC's entire product line (which are geared specifically to deal with the 
  220. numerous different markets (as Moore describes them ... the doctors and the engineers) in the 
  221. Information Sciences world.
  222.  
  223. OTOH, if you mention something on meterware that I (or anyone else) wants to pursue further, I have 
  224. no problem with piping in here or in OS2Share....
  225.  
  226.   --Sam. (Warped & using GCP 2.22)
  227.     sam_little@iacnet.com
  228.  
  229.  
  230.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  231.  To:    Samuel G. Little, 70544,10    Wednesday, January 03, 1996 11:31:16 AM
  232.  From:    Jon Duringer[IdeaFa, 71732,3361    #70065
  233.  
  234. >> some packages may have many subsystems fitting into a whole range from the innovative to the 
  235. now-mundane. Is such a system more or less difficult to market?
  236.  
  237. With conventional channels, we ask the customer to purchase the software and we set a price.  Your 
  238. observation suggests that the advanced features won't be appreciated (or even wanted) by some 
  239. users, while the mundane features won't excite the innovator and early adopter users.  The problem 
  240. here is that you're trying to sell the same software to everyone.
  241.  
  242. Now consider distributing the same software as meterware.  First, you would identify the menu items 
  243. that are mundane and the menu items that are advanced.  You'd call the Sally Sales (tm) API each 
  244. time a menu item is selected, and you'd specify either the authorId for mundane or the authorId for 
  245. advanced.  You'd set two prices for the product, one for the mundane features and the other for the 
  246. advanced.  Finally, you'd design two independent marketing programs, one targeting the late 
  247. majority and one targeting the early adopters.
  248.  
  249. With meterware, there is no limit to this.  Everyone gets the software itself for free, so there's no 
  250. hassle.  If you want to, you can market each and every menu item (even if there are hundreds) as a 
  251. separate product, using a separate price and a separate marketing program.
  252.  
  253.  
  254. >> I know very little about [meterware]
  255.  
  256. Pick whatever product interests you, and learn enough about it to use as your "case example" as 
  257. you read Moore.  Anyone who chooses the problem of "how to launch a meterware community" can 
  258. discuss the particulars with me over in the Issues section of OS2SHARE.  One benefit of picking 
  259. meterware is that you'd become familiar with meterware and would be involved in actually working 
  260. on a real marketing problem rather than just talking about what someone -else- is doing.
  261.  
  262.  
  263.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  264.  To:    Jon Duringer[IdeaFa, 71732,3361    Sunday, January 07, 1996 10:21:16 AM
  265.  From:    Shmuel Metz (Atid/2), 71054,3066#70484
  266.  
  267. You're missing a critical stage in the marketing of meterware software; convincing the user to 
  268. download and install the software. Only if the user is willing to do this is there an issue of convincing 
  269. him to use it more heavily. Note that shareware has the same problem; you have to convince the 
  270. user to try it before you can convince him to register it.
  271.  
  272. In both cases trying out the software involves a certain amount of expense on the user's part, mostly 
  273. in the form of manpower. An effective promotion of the software must take this into account.
  274.  
  275.  
  276. Shmuel (Seymour J.) Metz, SysProg & JOAT, Atid/2, Team OS/2, Team PL/I
  277.  
  278.  
  279.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  280.  To:    Shmuel Metz (Atid/2), 71054,3066Sunday, January 07, 1996 1:29:13 PM
  281.  From:    Jon Duringer[IdeaFa, 71732,3361    #70503
  282.  
  283. >> You're missing a critical stage in the marketing of meterware software; convincing the user to 
  284. download and install the software... expense on the user's part, mostly in the form of manpower
  285.  
  286. I'll tell you why I resist d/l'ing s/w.  (1) Will it be easy to install?  (2) Will it be easy to remove?  (3) Will it 
  287. politely refrain from touching the other objects in my computer?
  288.  
  289. It only takes three words of marketing to overcome this resistance:  YES, YES, YES.  IOW, the 
  290. obstacle that you are highlighting is -not- overcome in marketing; it is overcome by the code crafter.
  291.  
  292.  
  293.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  294.  To:    Samuel G. Little, 70544,10    Wednesday, January 03, 1996 11:31:16 AM
  295.  From:    Jon Duringer[IdeaFa, 71732,3361    #70065
  296.  
  297. >> some packages may have many subsystems fitting into a whole range from the innovative to the 
  298. now-mundane. Is such a system more or less difficult to market?
  299.  
  300. With conventional channels, we ask the customer to purchase the software and we set a price.  Your 
  301. observation suggests that the advanced features won't be appreciated (or even wanted) by some 
  302. users, while the mundane features won't excite the innovator and early adopter users.  The problem 
  303. here is that you're trying to sell the same software to everyone.
  304.  
  305. Now consider distributing the same software as meterware.  First, you would identify the menu items 
  306. that are mundane and the menu items that are advanced.  You'd call the Sally Sales (tm) API each 
  307. time a menu item is selected, and you'd specify either the authorId for mundane or the authorId for 
  308. advanced.  You'd set two prices for the product, one for the mundane features and the other for the 
  309. advanced.  Finally, you'd design two independent marketing programs, one targeting the late 
  310. majority and one targeting the early adopters.
  311.  
  312. With meterware, there is no limit to this.  Everyone gets the software itself for free, so there's no 
  313. hassle.  If you want to, you can market each and every menu item (even if there are hundreds) as a 
  314. separate product, using a separate price and a separate marketing program.
  315.  
  316.  
  317. >> I know very little about [meterware]
  318.  
  319. Pick whatever product interests you, and learn enough about it to use as your "case example" as 
  320. you read Moore.  Anyone who chooses the problem of "how to launch a meterware community" can 
  321. discuss the particulars with me over in the Issues section of OS2SHARE.  One benefit of picking 
  322. meterware is that you'd become familiar with meterware and would be involved in actually working 
  323. on a real marketing problem rather than just talking about what someone -else- is doing.
  324.  
  325.  
  326.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  327.  To:    Samuel G. Little, 70544,10    Saturday, January 06, 1996 6:59:02 PM
  328.  From:    Charles Stirling, 100010,1433    #70447
  329.  
  330.  > I was thinking somewhat about apps that "fuse" disparate product
  331.  > elements ... things that are innovative in some way, yet
  332.  > conservative in others.
  333.  
  334.  > some packages may have many subsystems fitting into a whole range
  335.  > from the innovative to the now-mundane. Is such a system more or
  336.  > less difficult to market?
  337.  
  338. Wouldn't this depend more on what the use "sees" of the product then the underlying innovativness 
  339. of parts of it?  If a product is doing something really new then getting across what this is will be the 
  340. difficult part to any category of user.
  341.  
  342. If it is how something is done, such as a new interface, then two aspects seem to come into it.
  343.     1. Time, the user interested will have to have the inclination to take the time to learn it and this 
  344. may well be the innovators, early adopters who will try it to see if it does something better.  Such as a 
  345. frame based word processor.
  346.  
  347.     2. Offers an obvious improvement then it can quickly become a new standard and has wider 
  348. category of user appeal.  Like the little help windows that pop up under a curser -- these have only 
  349. been around for a relativly few years, but are now almost a necessity.
  350.  
  351. If the inovation is behind the sceans then only the innovators, early adopters will be interested.  Like 
  352. "Rushmore ?sp" in FoxPro.  So, if it is in this catigory then marketing at this group needs to 
  353. emphasize this advantage, but only in the technical write ups.  If it is more apparant first an 
  354. explanation of what is differant, i.e. frames, needs to be made than why it is better for particular uses.
  355.  
  356. I don't think this makes a product more difficult to market, but does need differant marketing and may 
  357. influance how quick a product is taken up.  The advantages must be spelled out whatever, just in 
  358. differant ways.  If it is a totally new catigory of application, like Notes, then trying to get what it actually 
  359. does must be the focus of marketing.
  360.  
  361. Charles
  362.  
  363.  
  364.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  365.  To:    Shmuel Metz (Atid/2), 71054,3066Monday, January 01, 1996 10:31:16 PM
  366.  From:    Samuel G. Little, 70544,10    #69901
  367.  
  368.  > Not even BG could write a PIM less user friendly than that
  369.  > disorderly pad of paper.
  370.  
  371. Oh, sure he could. The problem with pen and paper isn't so much the input interface, but the retrieval 
  372. engine. All it would take is to file Information in a way so that it isn't easily searchable, or put 
  373. everything on the same "piece of paper" and you've got the same problem.
  374.  
  375.   --Sam. (Warped & using GCP 2.22)
  376.     sam_little@iacnet.com
  377.  
  378.  
  379.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  380.  To:    Jerry  Golick, 71175,1011    Friday, January 05, 1996 3:21:01 PM
  381.  From:    Charles Stirling, 100010,1433    #70343
  382.  
  383. Jerry,
  384.  
  385. I guess I feal that "object-centric" is too programer in sound and application-centric isn't the way 
  386. forward, guess I would preferr "document - centric" as the term.  Would like the administrative 
  387. functions easier to deal with than changing the battery in my watch, takes hours trying to find 
  388. someone who stocks the right one <g>.
  389.  
  390. "3)"  Will agree writing one large program to do everything isn't the way, but want the objects to all be 
  391. integrated and supplied together to do this elusive everything. For instance, I've been thinking of 
  392. DeScribe and watching the posting, the list of what is wanted by various users grows almost 
  393. exponentially untill some temporary saturation point is reached then will start off again as new 
  394. possibilities (say HTML) come along.  It is just difficult to predict what I will want to use next, so want 
  395. as many features as possible just in case.  I do like the choice of being able to load or not a 
  396. particular feature.
  397.  
  398. I am probably wrong, but get some impression the idea with "objects" is that you would buy them 
  399. individually as a customer and it is this aspect that I suspect has me worried about the concept.  As 
  400. for actually programing with object, yes.  It's the marketing aspect I wonder about.
  401.  
  402. Charles
  403.  
  404.  
  405.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  406.  To:    Jon Duringer[IdeaFa, 71732,3361    Saturday, January 06, 1996 6:59:06 PM
  407.  From:    Charles Stirling, 100010,1433    #70448
  408.  
  409.  > Pads of paper -are- limited in what can be done with them.  But
  410.  > they are a good example of products that do not need user's
  411.  > manuals.
  412.  
  413. This assumes a common understanding built up with familiarity.  Software starts to have this when an 
  414. application can be loaded and run without the manual its just that many have not yet developed this 
  415. common understanding and must be catered for or that conventions are broaken so the "common 
  416. understanding" no longer exists.  As it gets more complex of course their will be fewer and few with 
  417. this understanding.
  418.  
  419.  
  420.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  421.  To:    Charles Stirling, 100010,1433    Sunday, January 07, 1996 8:58:19 AM
  422.  From:    Jon Duringer[IdeaFa, 71732,3361    #70481
  423.  
  424. >> This assumes a common understanding built up with familiarity.
  425.  
  426. Yes, pads of paper do not need a manual because they are familiar, not because they are 
  427. intrinsically simple.  If I hand a pad of paper to someone who has never seen paper before, but who 
  428. has drawn charcoal paintings on cave walls, she would probably destroy it before discovering what 
  429. to do with it.
  430.  
  431.  
  432. >> Software starts to have this when an application can be loaded and run without the manual
  433.  
  434. Another requirement is that the user know, before hand, that she will be able to completely -uninstall- 
  435. the product and that there will be no permanent effects on her computer.  IOW, other objects will 
  436. continue to work.
  437.  
  438. Your comment makes me think that these "quality issues" can also be viewed as marketing issues, 
  439. because they erect obstacles for the customer who's attention has been attracted but who will resist 
  440. touching the product because it might burn.
  441.  
  442. IOW, we are like sellers of children's toys who display the toys sitting on hot plates.  We say, "See 
  443. our pretty toys!  Pick them up!  They are fun to handle!".  But the children have learned from 
  444. experience that some of the toys that they pick up burn their fingers.  And we, behind the counter, 
  445. wonder why it is so difficult to get the children to pick up a newly displayed toy!
  446.  
  447.  
  448.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  449.  To:    Jon Duringer[IdeaFa, 71732,3361    Sunday, January 07, 1996 10:21:24 AM
  450.  From:    Shmuel Metz (Atid/2), 71054,3066#70485
  451.  
  452. >> A sentient object has a personality. <<
  453.  
  454. IMHO there are too many anthropomorphisms in this thread. The objects that you have described, 
  455. e.g., Sally Sales, are not sentient and do not have personalities. Sentience is far more than simple 
  456. conditional logic. Contrast the behaviors of Eliza and Sally Sales.
  457.  
  458. Sentience and personality are both complex concepts involving many facets. In particular, adaption 
  459. and complexity are key components in what we consider sentience. The behavior of a 100 line C++ 
  460. program is qualitatively different from that of an expert system with 20,000 rules.
  461.  
  462. Note that I am not addressing the question of whether sentience and personality are within the state 
  463. of the art; that topic belongs in another forum. But if it's possible, it will require a *lot* of code.
  464.  
  465.  
  466. Shmuel (Seymour J.) Metz, SysProg & JOAT, Atid/2, Team OS/2, Team PL/I
  467.  
  468.  
  469.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  470.  To:    Jon Duringer[IdeaFa, 71732,3361    Sunday, January 07, 1996 10:22:02 AM
  471.  From:    Shmuel Metz (Atid/2), 71054,3066#70486
  472.  
  473. What you're talking about now is the difference between two kinds of interfaces, not on whether one 
  474. exists. A good interface will be accessible but unobtrusive. I want my emergency brake lever where I 
  475. can reach it, but not jabbing into my thigh.
  476.  
  477.  
  478. Shmuel (Seymour J.) Metz, SysProg & JOAT, Atid/2, Team OS/2, Team PL/I
  479.  
  480.  
  481.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  482.  To:    Herbert Ice, 72370,2501        Sunday, January 07, 1996 10:22:07 AM
  483.  From:    Shmuel Metz (Atid/2), 71054,3066#70487
  484.  
  485. ROTF,LMAO! Yes, that is what he would do.
  486.  
  487.  
  488. Shmuel (Seymour J.) Metz, SysProg & JOAT, Atid/2, Team OS/2, Team PL/I
  489.  
  490.  
  491.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  492.  To:    Jon Duringer[IdeaFa, 71732,3361    Sunday, January 07, 1996 10:22:15 AM
  493.  From:    Shmuel Metz (Atid/2), 71054,3066#70488
  494.  
  495. >> I can't decode this! <<
  496.  
  497. VI is the editor that everyone loves to hate. It is notorious for its user-hostile interface, but it is popular 
  498. because whatever EUnix <g> system you are on, you can count on its being available.
  499.  
  500.  
  501. >> This is a complaint about what you can do with a pad of paper.  It is not a complaint about how 
  502. easy it is to master the usage of a pad of paper. <<
  503.  
  504. Sorry, but I can and do do those things with a pad of paper; it's just not easy.
  505.  
  506.  
  507.  
  508. Shmuel (Seymour J.) Metz, SysProg & JOAT, Atid/2, Team OS/2, Team PL/I
  509.  
  510.  
  511.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  512.  To:    Des Dougan, 100553,2152        Sunday, January 07, 1996 10:22:21 AM
  513.  From:    Shmuel Metz (Atid/2), 71054,3066#70489
  514.  
  515. >> Happy new year to all OS/2 users, vendors and journalists. (God, that last bit was hard..). <<
  516.  
  517. The only hard part of say HNY to journalist is finding them; most of the people calling themselves 
  518. journalists are just hacks. Fortunately we have some of the real thing in these fora, but I wouldn't want 
  519. to give them swelled heads by singling them out.
  520.  
  521.  
  522.  
  523. Shmuel (Seymour J.) Metz, SysProg & JOAT, Atid/2, Team OS/2, Team PL/I
  524.  
  525.  
  526.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  527.  To:    Shmuel Metz (Atid/2), 71054,3066Sunday, January 07, 1996 12:39:07 PM
  528.  From:    Esther Schindler [EXEC], 72241,1417#70498
  529.  
  530.  > most of the people calling themselves journalists are just hacks.
  531.  
  532. Sorry, I disagree vehemently. I know entirely too many professional and intelligent computer industry 
  533. writers of integrity to let that generalization pass unchallenged.
  534.  
  535. You can _always_ find bozos, in any profession. But you don't hate all doctors because you 
  536. encountered one or two bad ones. You just hate the bad ones (and your disdain ain't _nothin'_ 
  537. compared to the ill will directed at those bad practitioners by their peers).
  538.  
  539. --Esther, defending her friends/cohort Rebecca, Judith, Jeff, Lisa, Steven, Stephen, JD, Dennis... and 
  540. a cast of thousands
  541.  
  542.  
  543.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  544.  To:    Shmuel Metz (Atid/2), 71054,3066Sunday, January 07, 1996 5:59:19 PM
  545.  From:    Des Dougan, 100553,2152        #70550
  546.  
  547. Shmuel,
  548.  
  549.  >>  Fortunately we have some of the  real thing in these fora, but I wouldn't
  550. want to give them swelled heads by  singling them out.  <<
  551.  
  552.  
  553. It's obvious that the _real_ journalists in this forum are too professional, modest and classy to be 
  554. affected by ego <bg>!
  555.  
  556. Des Dougan at 14:54:27 PT 07-Jan-96 
  557.  
  558.  
  559.  
  560.  Subj:    framing the problem        Section: Marketing OS/2 Apps
  561.  To:    Jon Duringer[IdeaFa, 71732,3361    Sunday, January 07, 1996 10:22:27 AM
  562.  From:    Shmuel Metz (Atid/2), 71054,3066#70490
  563.  
  564. >> No one submits a requisition.  No one issues a PO. <<
  565.  
  566. You've just brought out a problem with the meterware concept; it interferes with management's ability 
  567. to audit and budget software expenditures. The auditors will eat your lunch if you don't find a way to 
  568. keep them happy.
  569.  
  570. >> The meterware market will be characterized by zero resistance to sales, because there is no 
  571. longer a sale. <<
  572.  
  573. You may not chose to consider it a sale, but you have to convince the user to download and install 
  574. the software before you can get him to use it. If you prefer to call it acquisition resistance, fine, but IAC 
  575. it has the same practical effect as sales resistance.
  576.  
  577.  
  578.  
  579. Shmuel (Seymour J.) Metz, SysProg & JOAT, Atid/2, Team OS/2, Team PL/I
  580.  
  581.  
  582.  
  583.