Re: Realtime use-case's

Hi Thomas,

I share your general position (stated in the last paragraph of your 
message below).

I believe it can be paraphrased as follows: there is (in principle) be 
no distinction in the data format used in a "real time" use case and one 
which is not real time.

In fact, real time and non real time can (should) use precisely the same 
data format and should (must) be totally independent of the architecture 
of the application (e.g., data format identical when data is all local, 
partly local data, all remote).

This means the same experience for the user if the bandwidth is 
unlimited and the protocol is lightweight as the user experience if the 
data is all local.

Does anyone believe this is a false assumption to make? What issues does 
it raise?

If the above is generally considered a "fair assumption", the logical 
extension of this is that there is no need to distinguish between a real 
time use case and a non-real time use case.

Further on the topic of use cases.

I am unclear if the use cases need to be as specific as you describe or 
if they can be more general.

In Seoul the participants of the International AR Standards meeting 
described three AR use case (they are actually categories of use cases).

They have been described several times in conf calls, are depicted 
visually in an output of the International AR Standards meeting and can 
be summarized for completeness and quick reference as follows:

A. Guide: a system which leads the user through a process involving the 
real world

B. Create: a system with which the user attaches/contributes a digital 
"object" to or in the real world

C. Play: a system which supports bi-directional interaction between two 
or more users in and with the real world

I will now connect the dots (as I see them) between the above use cases 
and those you suggest below.

1. tracking of friends or exploration (tourism applications)

for me, these are all specific conditions of the Guide use case.

2. using AR to obtain information about a moving object which the user 
can then use to make a decision

for me this is also a Guide use case which includes all the "what's 
around me?" use cases

3. tracking celestial bodies

another example of "what's around me?"

4. game in/with the real world

possibly a subcase of Play use case

I think in order to move discussion forward on the topic of use cases, 
we must understand what (precisely) needs to be "known" or included 
about the complete use case to inform the definition of a suitably 
flexible and broaddata format.

Christine

Spime Wrangler

cperey@perey.com
mobile +41 79 436 6869
VoIP +1 (617) 848-8159
Skype Christine_Perey


On 12/10/10 2:57 AM, Thomas Wrobel wrote:
> Seeing as the topic of real-time use case's came up recently, I
> thought Id suggest a few rough ones for discussion or refinement;
>
> 1. Tracking your friends locations when going to an outdoor event, or
> exploring a city while on Holiday. I picture a simple "arrows from the
> sky" depiction in the view, with each arrow being updated
> independently above your friends every few seconds. The arrows should
> only be visible to the friends/family members that have permission to
> see the stream.
> Additionally, fully public, possibly not-realtime elements should be
> scene at the same time, such as a city map overlaid in the sky.
>
> 2. Public transport tracking system. Holding your viewing client to
> bus/train stops gives you eta's of things arriving and notices of
> delays etc. Updated as new information comes in.
>
> 3. Astronomy overlay, which shows the paths and position of heavenly
> bodies as they pass though the sky. This angular position of these
> objects in the sky would naturally have to change based on the time of
> day. Nasa or Esa might also supply a update stream of their satellite
> positions or other less predictable craft.
>
> 4. A Pokemon-esq game played in a local park. Players see their
> creatures battling around them, the creatures responding to commands
> given.
>   While the game rules are dealt with by a dedicated server, the data
> is published out in a standard format, so bystanders can watch easily
> with generic AR browser software.
>
>
> My own view;
>
> I personally feel the realtime, as well as social, is a massive area
> for AR and should be carefully considered to ensure as flexible
> a system as possible. However, I think for most circumstances,
> realtime use affects more the protocol of data transmission then the
> content itself. That is, the same format of key/value pairs
> positioning stuff statically on a http based webserver, could also be
> used to reposition stuff dynamically every few seconds over, say, a
> xmpp based stream.(which also allows for  selective viewing, such as
> in usecase1 above)
>
> As long as the format stays neutral to the transmission method (ie,
> not one strictly relaying on a webpage structure), and the required
> POI format is lightweight enough, I -think- realtime use should be a
> "free" possibility without extra effort.
>
> -Thomas wrobel
>
> ~~~~~~
> Reviews of anything, by anyone;
> www.rateoholic.co.uk
> Please try out my new site and give feedback :)
>
>
>