Difference between revisions of "Talk:AWG Use Cases"

From Second Life Wiki
Jump to navigation Jump to search
(Undo revision 1199997 by Nancygoz Resident (talk) repeat of term paper spammer)
 
(15 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Strategic Scope ==
== Strategic Scope ==
* The figures given in the "Create a system" line are not consistent with the figures given in [[Project_Motivation]].  They don't have to be the same of course, since the initial target might be just an early step in the direction of the ''scary numbers''.  If this is the case though, then all the numbers should ideally be scaled proportionally, unless a reason is given for disparate scaling. --[[User:Morgaine Dinova|Morgaine Dinova]] 04:08, 26 September 2007 (PDT)
* The figures given in the "Create a system" line are not consistent with the figures given in [[Project_Motivation]].  They don't have to be the same of course, since the initial target might be just an early step in the direction of the ''scary numbers''.  If this is the case though, then all the numbers should ideally be scaled proportionally, unless a reason is given for disparate scaling. --[[User:Morgaine Dinova|Morgaine Dinova]] 04:08, 26 September 2007 (PDT)
** I've now replaced the 500m/500k which lacked justification with a reference to those in [[Project_Motivation]]. --[[User:Morgaine Dinova|Morgaine Dinova]] 04:17, 27 September 2007 (PDT)
* Replaced the reference to "preserving DRM" by "retaining permissions", since DRM is a different concept entirely (despite the words in D.R.M.) -- see [[Protecting_content_in_an_open_grid#The_fallacy_of_DRM|The Fallacy of DRM]].  SL does not use DRM to implement permissions, as Lindens have explained. --[[User:Morgaine Dinova|Morgaine Dinova]] 06:13, 9 October 2007 (PDT)
* Replaced "preserving" by "evolving" in the reference to the micropayment economy, because the sentence was ambiguous (did it mean preserving micropayments, or preserving the economy?) and because the economy certainly won't be be locked in statis, but will evolve as the platform evolves.  The word "evolve" does at least convey the idea of short-term stability, which is what the original line probably intended. --[[User:Morgaine Dinova|Morgaine Dinova]] 06:13, 9 October 2007 (PDT)


== System Scope ==
== System Scope ==
=== Viewer-related use cases ===
* Tillie, I liked the suggestion you attached to the [[Use_Cases#Guild Wars "Observer Mode" like setup -- Interactive TV|Guild Wars "Observer Mode"]] use case, so when I added my SL-specific case for it in [[Use_Cases#Interactive TV|Interactive TV]], I followed it up with your idea as another use case, [[Use_Cases#Interactive TV|Non-Interactive TV]]. --[[User:Morgaine Dinova|Morgaine Dinova]] 14:59, 26 September 2007 (PDT)
====  Extended Capabilities Viewer ====
Added section with a few examples. [[User:Saijanai Kuhn|Saijanai]] 09:20, 7 October 2007 (PDT)
==== Game clients ====
Added section with a list of typical attributes for this class. --[[User:Morgaine Dinova|Morgaine Dinova]] 05:49, 9 October 2007 (PDT)


== Some possible futuristic scenarios ==
== Some possible futuristic scenarios ==
* Added a Use Case for the '''Observer Mode''' of Guild Wars, which is effectively "interactive TV" and hence could be massive. --[[User:Morgaine Dinova|Morgaine Dinova]] 04:49, 26 September 2007 (PDT)
* Added a Use Case for the '''Observer Mode''' of Guild Wars, which is effectively "interactive TV" and hence could be massive. --[[User:Morgaine Dinova|Morgaine Dinova]] 04:49, 26 September 2007 (PDT)


This feature is critical when it comes to privacy. Currently you see all other avatars in range. Might be a problem for some locations, think of sex clubs. Another example could be education etc, eg. classes. Many classes held in SL are being paid by the students. For these cases there must be a possibility to lock out observers. --[[User:Tillie Ariantho|Tillie Ariantho]]
:*This feature is critical when it comes to privacy. Currently you see all other avatars in range. Might be a problem for some locations, think of sex clubs. Another example could be education etc, eg. classes. Many classes held in SL are being paid by the students. For these cases there must be a possibility to lock out observers. --[[User:Tillie Ariantho|Tillie Ariantho]]
::* Seconded, very strongly.  Privacy becomes an extremely important matter as we scale this across the big bad world, and it's more than just a matter of avoiding embarrassment ... in many places it's a matter of life and death.  It requires serious consideration within the new architecture. --[[User:Morgaine Dinova|Morgaine Dinova]] 13:53, 26 September 2007 (PDT)
 
* I've moved "'''Second Life As We Know It Set-Up'''" out of this section, since its placement here made no logical sense.  I've promoted it up the section tree too since it would make no sense under '''Use Case capturing''' either. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:31, 6 November 2007 (PST)
 
=== Thoughts on Use Cases ===
 
Right now, this list is all inclusive, and we are in a phase of simply adding to it.  Since use cases all represent something someone has seen a possible reason to do, there is no such thing as a wrong use case.  Eventually, however, we will have to triage these down into categories like:
:* Must be directly supported
:* Should be possible though implementation choices, but not directly supported
:* Leave for the future
:* Incompatible with other use cases - sometimes there are conflicts of interest
[[User:Zero Linden|Zero Linden]] 11:16, 16 October 2007 (PDT)
 
* That doesn't look right to me on the first three fronts, and the 4th needs special care as well:
:* Use cases are envisaged cases of usage, not implementation cases.  The fact that a (valid) use case isn't supported reflects a problem with support, not with the use case.  By all means cull use cases on the basis of viability or sanity or technical coherence and so on, but the non-existence of an implementation is not a valid basis for culling.  Indeed, the opposite is true:  the existence of a use case substantiates the delivery of support for it, and not vice versa.
:* Implementation choices are made differently by different parties.  In a distributed universe or supergrid, a diversity of choices should be expected.  LL will pick only a subset of the available choices.
:* Use cases very commonly arise out of ''vision'' (cue Philip), so "leave for the future" is very much business as usual for a proportion of them.  Indeed, we only need to start worrying when there are no more unsupported use cases on the table.  It would then be time to move onto something more visionary and ambitious.
:* Incompatibility can be a good reason for not supporting a valid use case, but one needs to define the issue with precision or else this can become a catchall for indefensible excuses.  I agree that there can be conflicts of interest:  for example it is possible to envisage a ''hypothetical'' conflict of interest between wishing to sell more grid servers and wishing to make regions more scalable.  However, such non-technical conflicts of interest are not really of interest to AWG, I feel.  Instead, I suggest that we limit ourselves to technical conflicts of interest, which are subject to normal engineering tradeoffs.
--[[User:Morgaine Dinova|Morgaine Dinova]] 07:34, 6 November 2007 (PST)

Latest revision as of 04:14, 27 April 2016

Strategic Scope

  • The figures given in the "Create a system" line are not consistent with the figures given in Project_Motivation. They don't have to be the same of course, since the initial target might be just an early step in the direction of the scary numbers. If this is the case though, then all the numbers should ideally be scaled proportionally, unless a reason is given for disparate scaling. --Morgaine Dinova 04:08, 26 September 2007 (PDT)
  • Replaced the reference to "preserving DRM" by "retaining permissions", since DRM is a different concept entirely (despite the words in D.R.M.) -- see The Fallacy of DRM. SL does not use DRM to implement permissions, as Lindens have explained. --Morgaine Dinova 06:13, 9 October 2007 (PDT)
  • Replaced "preserving" by "evolving" in the reference to the micropayment economy, because the sentence was ambiguous (did it mean preserving micropayments, or preserving the economy?) and because the economy certainly won't be be locked in statis, but will evolve as the platform evolves. The word "evolve" does at least convey the idea of short-term stability, which is what the original line probably intended. --Morgaine Dinova 06:13, 9 October 2007 (PDT)

System Scope

Viewer-related use cases

Extended Capabilities Viewer

Added section with a few examples. Saijanai 09:20, 7 October 2007 (PDT)

Game clients

Added section with a list of typical attributes for this class. --Morgaine Dinova 05:49, 9 October 2007 (PDT)

Some possible futuristic scenarios

  • Added a Use Case for the Observer Mode of Guild Wars, which is effectively "interactive TV" and hence could be massive. --Morgaine Dinova 04:49, 26 September 2007 (PDT)
  • This feature is critical when it comes to privacy. Currently you see all other avatars in range. Might be a problem for some locations, think of sex clubs. Another example could be education etc, eg. classes. Many classes held in SL are being paid by the students. For these cases there must be a possibility to lock out observers. --Tillie Ariantho
  • Seconded, very strongly. Privacy becomes an extremely important matter as we scale this across the big bad world, and it's more than just a matter of avoiding embarrassment ... in many places it's a matter of life and death. It requires serious consideration within the new architecture. --Morgaine Dinova 13:53, 26 September 2007 (PDT)
  • I've moved "Second Life As We Know It Set-Up" out of this section, since its placement here made no logical sense. I've promoted it up the section tree too since it would make no sense under Use Case capturing either. --Morgaine Dinova 09:31, 6 November 2007 (PST)

Thoughts on Use Cases

Right now, this list is all inclusive, and we are in a phase of simply adding to it. Since use cases all represent something someone has seen a possible reason to do, there is no such thing as a wrong use case. Eventually, however, we will have to triage these down into categories like:

  • Must be directly supported
  • Should be possible though implementation choices, but not directly supported
  • Leave for the future
  • Incompatible with other use cases - sometimes there are conflicts of interest

Zero Linden 11:16, 16 October 2007 (PDT)

  • That doesn't look right to me on the first three fronts, and the 4th needs special care as well:
  • Use cases are envisaged cases of usage, not implementation cases. The fact that a (valid) use case isn't supported reflects a problem with support, not with the use case. By all means cull use cases on the basis of viability or sanity or technical coherence and so on, but the non-existence of an implementation is not a valid basis for culling. Indeed, the opposite is true: the existence of a use case substantiates the delivery of support for it, and not vice versa.
  • Implementation choices are made differently by different parties. In a distributed universe or supergrid, a diversity of choices should be expected. LL will pick only a subset of the available choices.
  • Use cases very commonly arise out of vision (cue Philip), so "leave for the future" is very much business as usual for a proportion of them. Indeed, we only need to start worrying when there are no more unsupported use cases on the table. It would then be time to move onto something more visionary and ambitious.
  • Incompatibility can be a good reason for not supporting a valid use case, but one needs to define the issue with precision or else this can become a catchall for indefensible excuses. I agree that there can be conflicts of interest: for example it is possible to envisage a hypothetical conflict of interest between wishing to sell more grid servers and wishing to make regions more scalable. However, such non-technical conflicts of interest are not really of interest to AWG, I feel. Instead, I suggest that we limit ourselves to technical conflicts of interest, which are subject to normal engineering tradeoffs.

--Morgaine Dinova 07:34, 6 November 2007 (PST)