Talk:Service cycle: Difference between revisions
m (Awww. Gimme a break with this audio...) |
(Develop->Research->Publish->Signal->Feedback->Develop) |
||
(One intermediate revision by one other user not shown) | |||
Line 16: | Line 16: | ||
:::Awww. Gimme a break with this audio. We are living in such a '''signal infested''' world that I really don't want any audio widgets to guide shopping. | :::Awww. Gimme a break with this audio. We are living in such a '''signal infested''' world that I really don't want any audio widgets to guide shopping. | ||
::::It doesn't matter what YOU want. Perhaps uncomfortable signals or just encouraging words have the psychological impact whether you want it or not, and failure is inevitable until they are there. But if it matters what you awnt, it matters also what [[DanKeshet]] wants, and he wants [[print]]. So we have one advocate each for [[audio]], [[video]], and [[Paper Consumerium]]. But [[audio]] has the [[speed]] edge. And that's going to be the most critical of all [[performance requirements]]. Which is exactly why you deleted that file, we trolls suspect. It's a typical form of [[sysop]] power abuse, which is, delete the requirements you know you can't meet. It's done even in big hardware companies! Usually this only destroys companies. But the [[Lowest Troll]] should be more careful, as it might in this case destroy rainforests. | |||
and only then what [[Consumerium Process]] is. | and only then what [[Consumerium Process]] is. | ||
:The whole management ([[govenance]]) issue boils down to "What is the [[Consumerium Process]]". | :The whole management ([[govenance]]) issue boils down to "What is the [[Consumerium Process]]". | ||
:::Neatly stated as "Develop->Research->Publish->Signal->Feedback->Develop" [[service cycle]] of [[Consumerium:Itself]]. | |||
Since the services are what we want to represent, and the access must happen as decisions are made about the services, and then the process is trying to keep those decisions up to date with current assertions about the services, it seems we probably have to go in that order. | Since the services are what we want to represent, and the access must happen as decisions are made about the services, and then the process is trying to keep those decisions up to date with current assertions about the services, it seems we probably have to go in that order. | ||
:see above about [[Checkout Consumerium]]: '''buy, examine, re-evaluate, buy different''' --[[User:Juxo|Juxo]] 15:03, 16 Mar 2004 (EET) | :see above about [[Checkout Consumerium]]: '''buy, examine, re-evaluate, buy different''' --[[User:Juxo|Juxo]] 15:03, 16 Mar 2004 (EET) |
Latest revision as of 23:51, 30 March 2004
Maybe this must be figured out in depth first, filled in,
- Yes. It must be investigated under which kinds of terms and what reliability this information is available from companies and what must our Researchers find out. Many companies do in-house studies on these issues and report them as environmental reports and social reports similar to fiscal reports
- What is a feasible level of Service cycle information we aim to provide the consumer with.
and only then can we figure out when Consumerium Service access happens,
- It seems clearer that Checkout Consumerium is likely the first in-store Consumerium Service to be made available. We should start researching the field of retail systems, who makes them, how are they integrated, what kind of platform and what software they run. I guess the Linux-players are more likely to be on the same wave-lenght as us.
- No, they are not there. Look at cash register makers. It's easier to deal with 3 global cash register makers than 3000000 free software geeks, each one of which has his own ideology and version of Linux. Hmm talk about bad copy problem!
NFC systems embedded into mobile phones and checkout terminals would be the lowest-tech solution that would enable consumers to access Consumerium Services with ease at home or in the office by examining what they just bought and then adjust their buying pattern accordingly.
- No, the easiest system for that is a tiny box that gets added on to the cash register via some primitive serial port, and updates your Consumerium Card or prints special coupons to help you change your buying habits. As the cash register rings up what was actually bought, the green or red light goes off on the box, and you hear a sound praising or razzing you - audio, remember? Most people will do anything to be praised in an appealing voice.
- Awww. Gimme a break with this audio. We are living in such a signal infested world that I really don't want any audio widgets to guide shopping.
- It doesn't matter what YOU want. Perhaps uncomfortable signals or just encouraging words have the psychological impact whether you want it or not, and failure is inevitable until they are there. But if it matters what you awnt, it matters also what DanKeshet wants, and he wants print. So we have one advocate each for audio, video, and Paper Consumerium. But audio has the speed edge. And that's going to be the most critical of all performance requirements. Which is exactly why you deleted that file, we trolls suspect. It's a typical form of sysop power abuse, which is, delete the requirements you know you can't meet. It's done even in big hardware companies! Usually this only destroys companies. But the Lowest Troll should be more careful, as it might in this case destroy rainforests.
and only then what Consumerium Process is.
- The whole management (govenance) issue boils down to "What is the Consumerium Process".
- Neatly stated as "Develop->Research->Publish->Signal->Feedback->Develop" service cycle of Consumerium:Itself.
Since the services are what we want to represent, and the access must happen as decisions are made about the services, and then the process is trying to keep those decisions up to date with current assertions about the services, it seems we probably have to go in that order.
- see above about Checkout Consumerium: buy, examine, re-evaluate, buy different --Juxo 15:03, 16 Mar 2004 (EET)