Talk:Intershop comparison - Revision history

142.177.114.78: situations where price data is desirable to integrate, or even maybe necessary - seems like it must be an open door

2004-03-14T00:34:18Z

situations where price data is desirable to integrate, or even maybe necessary - seems like it must be an open door

← Older revision		Revision as of 00:34, 14 March 2004
Line 3:		Line 3:
	1. how, exactly, is one to prevent [[intershop comparison]] from being provided by an add-on service? What [[Consumerium License]] provisions specifically say "you can't do this, and we can yank your access to the data if you do"?		1. how, exactly, is one to prevent [[intershop comparison]] from being provided by an add-on service? What [[Consumerium License]] provisions specifically say "you can't do this, and we can yank your access to the data if you do"?
	:<pre>Including explicit price data in your submissions is explicitly forbidden in [[Consumerium]].		:<pre>Including explicit price data in your submissions is explicitly forbidden in [[Consumerium]].
	Any such data will be removed if found in [[Research Wiki]] or [[Signal Wiki]]
			::Any such data will be removed if found in [[Research Wiki]] or [[Signal Wiki]]
	You may include verbal descriptions of pricing policies of different companies,		You may include verbal descriptions of pricing policies of different companies,
	but no numerical data whether as in price or percentage will be allowed</pre> --[[User:Juxo\|Juxo]] 16:59, 13 Mar 2004 (EET)		but no numerical data whether as in price or percentage will be allowed</pre> --[[User:Juxo\|Juxo]] 16:59, 13 Mar 2004 (EET)

			:::So the [[Consumerium License]] doesn't apply to such data, or forbids its integration within [[Consumerium Services]]? Be specific. You can't use words like "forbidden", or "may" or "will be removed" or "allowed". You have to describe how it is actually detected and removed in the [[Consumerium Process]].

			:::This doesn't prevent anyone from integrating [[Signal Wiki]] output into their own non-[[Consumerium buying signal]] that could include such data. It would be out of [[Consumerium Governance Organization]] control, assuming of course that they aren't distributing their own hardwired devices, which I must assume they are not. In general it might be better to provide clear ways to integrate [[price data]], for reasons outlined below:

	2. why, exactly, does the [[Development Wiki]]'s present concept of [[Features]] and their priority take precedence over what is required to implement [[best cases]]? A proper development process is motivated by its [[comprehensive outcome]] as expressed in [[use case]]s.		2. why, exactly, does the [[Development Wiki]]'s present concept of [[Features]] and their priority take precedence over what is required to implement [[best cases]]? A proper development process is motivated by its [[comprehensive outcome]] as expressed in [[use case]]s.

	:I haven't looked at the [[best cases]] in a while and when i did i found them to be quite [[utopia]]n (exept for those that were [[dystopia]]n) and to the ~~anwser~~ as to why there will be no explicit price data is to		:I haven't looked at the [[best cases]] in a while and when i did i found them to be quite [[utopia]]n (exept for those that were [[dystopia]]n)

			:::By all means take the ones you find [[dystopia]]n and write up [[worst cases]] to mirror them exactly. That's one of the reasons to have both. It's up to [[faction]]s anyway to say what they think is desirable versus not, same as political parties arguing over law. Yawn. Yes we can make even the most interesting things boring, so they can be settled. ;-)

			: and to the answer as to why there will be no explicit price data is to
	::A) No retailer, not even [[friendly retail]]er will want their price information to be licensed for any use that is not explicitly hoped and paid for by the retailer ie. [[advertising]]		::A) No retailer, not even [[friendly retail]]er will want their price information to be licensed for any use that is not explicitly hoped and paid for by the retailer ie. [[advertising]]
	::B) Including price data within the [[Wikis]] would ~~gepardise~~ our assumed neutrality.		:::But there's potential for advertising, e.g. "our price plus the [[price premium]] that according to your [[individual buying criteria]] you are willing to pay for our better product, is much better than the price for their [[red light]] product". That isn't possible though unless the price data is integrated. Else people have to do adding (!) of [[price premium]] in their own heads maybe, or remembering (!) whether it cost more in the other shop.
			::B) Including [[price data]] within the [[Wikis]] would jeopardise our assumed neutrality.
			:::(pardon casual fixes to spelling errors) Not if it's part of ordinary [[checkout counter]] functionality. That's what's done at that counter! It is certainly useful to calculate the actual price paid including the [[price premium]] (which could be positive or negative). So prices and premiums would be in one system in that case anyway, though it wouldn't be for [[intershop comparison]] purposes.
	::C) Keeping the price data exact and up-to-date would take too much resources		::C) Keeping the price data exact and up-to-date would take too much resources
			:::That's the store's problem. This is not an argument to make it difficult or impossible in the architecture. There are many potential applications that the stores may support, or third parties may want to add, and we can either control and allow for those, or not. I think worse things happen if you try to avoid any responsibility for this.

	3. If you have big problems or anticipate big problems with [[intershop comparison]], why is there nothing in [[worst cases]] explaining how it has bad consequences? Until there is, objections to this feature HAVE NO STATUS, and amount to nothing but feelings. This is similar to the [[betting]] issue. If you can't explain why it's bad, expect others to pursue it, until you can. If you're building an open architecture, you're going to see services you don't want implemented, implemented.		3. If you have big problems or anticipate big problems with [[intershop comparison]], why is there nothing in [[worst cases]] explaining how it has bad consequences? Until there is, objections to this feature HAVE NO STATUS, and amount to nothing but feelings. This is similar to the [[betting]] issue. If you can't explain why it's bad, expect others to pursue it, until you can. If you're building an open architecture, you're going to see services you don't want implemented, implemented.

	:We are likely to run into possibly bad attitudes in implementing [[Intershop navigation]], since some retailers will be afraid that the feature is driving customers to competing businesses. besides if you look at [[features]] it says that the implementation medium for [[Intershop navigation]] is yet undetermined since it requires some kind of [[GIS]]-engine to run such a service, which ~~undoubtably~~ would be useful.		:We are likely to run into possibly bad attitudes in implementing [[Intershop navigation]], since some retailers will be afraid that the feature is driving customers to competing businesses. besides if you look at [[features]] it says that the implementation medium for [[Intershop navigation]] is yet undetermined since it requires some kind of [[GIS]]-engine to run such a service, which undoubtedly would be useful.

			::"Likely", "possibly bad", "some", "afraid", bah. The [[Big Carrot]] is not afraid of this. They would probably like to be able to signal people over in the nearby stores that they have a product which is MUCH better for the Earth or their neighbours, and it costs a little more, but not more than the [[price premium]]. A [[Consumerium buying signal]] could take the form "there is something available for $24.35, which is only $19.95 given your [[price premium]], that does no damage to the planet and it is a two minute's walk away, do you want to buy this thing in front of you or not?" That lets the customer make the choice and doesn't require the un[[friendly retail]]'s help.

			::You have to lose this idea that all stores will be friendly. Many won't, and it is important to drive them out of business. ;-0

	4. Consider whether your view is [[faction]]al. To many people, price comparison is the first feature they'd want, and only later would they care about [[moral purchasing]].		4. Consider whether your view is [[faction]]al. To many people, price comparison is the first feature they'd want, and only later would they care about [[moral purchasing]].

	:The ones looking primarily for price comparison can go elsewhere. The internet is full of [[price comparison]]-services		:The ones looking primarily for price comparison can go elsewhere. The internet is full of [[price comparison]]-services

			:They have to be integrated eventually, certainly for Internet shopping, where people expect convenience and not to be adding up numbers in their own heads. It is a major opportunity to add [[moral purchasing]] to price comparison servers.

			----

			There's a lot of reasons to want this, and only some vague feelings not to. It seems to be something that ought to be explicitly allowed for in architecture.

Jukeboksi: anwsers to 142.177.X.X

2004-03-13T14:59:35Z

anwsers to 142.177.X.X

← Older revision		Revision as of 14:59, 13 March 2004
Line 2:		Line 2:

	1. how, exactly, is one to prevent [[intershop comparison]] from being provided by an add-on service? What [[Consumerium License]] provisions specifically say "you can't do this, and we can yank your access to the data if you do"?		1. how, exactly, is one to prevent [[intershop comparison]] from being provided by an add-on service? What [[Consumerium License]] provisions specifically say "you can't do this, and we can yank your access to the data if you do"?
			:<pre>Including explicit price data in your submissions is explicitly forbidden in [[Consumerium]].
			Any such data will be removed if found in [[Research Wiki]] or [[Signal Wiki]]
			You may include verbal descriptions of pricing policies of different companies,
			but no numerical data whether as in price or percentage will be allowed</pre> --[[User:Juxo\|Juxo]] 16:59, 13 Mar 2004 (EET)

	2. why, exactly, does the [[Development Wiki]]'s present concept of [[Features]] and their priority take precedence over what is required to implement [[best cases]]? A proper development process is motivated by its [[comprehensive outcome]] as expressed in [[use case]]s.		2. why, exactly, does the [[Development Wiki]]'s present concept of [[Features]] and their priority take precedence over what is required to implement [[best cases]]? A proper development process is motivated by its [[comprehensive outcome]] as expressed in [[use case]]s.

			:I haven't looked at the [[best cases]] in a while and when i did i found them to be quite [[utopia]]n (exept for those that were [[dystopia]]n) and to the anwser as to why there will be no explicit price data is to
			::A) No retailer, not even [[friendly retail]]er will want their price information to be licensed for any use that is not explicitly hoped and paid for by the retailer ie. [[advertising]]
			::B) Including price data within the [[Wikis]] would gepardise our assumed neutrality.
			::C) Keeping the price data exact and up-to-date would take too much resources

	3. If you have big problems or anticipate big problems with [[intershop comparison]], why is there nothing in [[worst cases]] explaining how it has bad consequences? Until there is, objections to this feature HAVE NO STATUS, and amount to nothing but feelings. This is similar to the [[betting]] issue. If you can't explain why it's bad, expect others to pursue it, until you can. If you're building an open architecture, you're going to see services you don't want implemented, implemented.		3. If you have big problems or anticipate big problems with [[intershop comparison]], why is there nothing in [[worst cases]] explaining how it has bad consequences? Until there is, objections to this feature HAVE NO STATUS, and amount to nothing but feelings. This is similar to the [[betting]] issue. If you can't explain why it's bad, expect others to pursue it, until you can. If you're building an open architecture, you're going to see services you don't want implemented, implemented.

			:We are likely to run into possibly bad attitudes in implementing [[Intershop navigation]], since some retailers will be afraid that the feature is driving customers to competing businesses. besides if you look at [[features]] it says that the implementation medium for [[Intershop navigation]] is yet undetermined since it requires some kind of [[GIS]]-engine to run such a service, which undoubtably would be useful.

	4. Consider whether your view is [[faction]]al. To many people, price comparison is the first feature they'd want, and only later would they care about [[moral purchasing]].		4. Consider whether your view is [[faction]]al. To many people, price comparison is the first feature they'd want, and only later would they care about [[moral purchasing]].

			:The ones looking primarily for price comparison can go elsewhere. The internet is full of [[price comparison]]-services

142.177.103.244: points to address before changing this again

2004-03-12T20:10:42Z

points to address before changing this again

New page

Some points you must address before you change this page:

1. how, exactly, is one to prevent [[intershop comparison]] from being provided by an add-on service? What [[Consumerium License]] provisions specifically say "you can't do this, and we can yank your access to the data if you do"?

2. why, exactly, does the [[Development Wiki]]'s present concept of [[Features]] and their priority take precedence over what is required to implement [[best cases]]? A proper development process is motivated by its [[comprehensive outcome]] as expressed in [[use case]]s.

3. If you have big problems or anticipate big problems with [[intershop comparison]], why is there nothing in [[worst cases]] explaining how it has bad consequences? Until there is, objections to this feature HAVE NO STATUS, and amount to nothing but feelings. This is similar to the [[betting]] issue. If you can't explain why it's bad, expect others to pursue it, until you can. If you're building an open architecture, you're going to see services you don't want implemented, implemented.

4. Consider whether your view is [[faction]]al. To many people, price comparison is the first feature they'd want, and only later would they care about [[moral purchasing]].