As I thought it might make sense to define the problem field before we
look for solutioins I posted a list of possible use cases to my blog
yesterday (http://mrtopf.de/blog/web20/use-cases-for-portable-social- networks/). Chris then asked me to put this on the use case page which
I did now:
Feel free to add your own problems you like to see solved to that list
so we can then think about ways to work on them (and probably we need
to find a scope for it).
I also now more or less copied it verbatim so feel free to adjust
these use cases accordingly, e.g. to make use of the definitions we
have in place.
For my idea about open social networks, maybe also have a look at
> As I thought it might make sense to define the problem field before we
> look for solutioins I posted a list of possible use cases to my blog
> yesterday (http://mrtopf.de/blog/web20/use-cases-for-portable-social- > networks/). Chris then asked me to put this on the use case page which
> I did now:
> Feel free to add your own problems you like to see solved to that list
> so we can then think about ways to work on them (and probably we need
> to find a scope for it).
> I also now more or less copied it verbatim so feel free to adjust
> these use cases accordingly, e.g. to make use of the definitions we
> have in place.
> For my idea about open social networks, maybe also have a look at
You wrote in the beginning: "The data model
The main object is a Person. A Person has a profile and contacts"
But I am a Person but I want 2, 3 or 4 profiles !! Not one !!
1 is for "public business activities"
2 is for "different business activities"
3 is for "private activities"
4 is ...
En example ? I work for a Big Computer Company in the US (Profile 1)
but in the same time I am looking to open a Hotel resort in France
(Profile 2) and I do not to mix the Profiles in a single Profile. And
I do not want a DOUBLE DATAPORTABILITY...
Netviber
On Jan 15, 2008 4:51 PM, Opo <netvi...@gmail.com> wrote:
> Hi, > Good work but...
> You wrote in the beginning: "The data model > The main object is a Person. A Person has a profile and contacts"
> But I am a Person but I want 2, 3 or 4 profiles !! Not one !! > 1 is for "public business activities" > 2 is for "different business activities" > 3 is for "private activities" > 4 is ...
Ah, right, actually I want this myself and many people esp. in Second Life want that, too. I missed this when writing it down so feel free to add the use cases for that.
And afaik this should also be possible with some OpenID providers, isn't it?
Now I wonder if this has any implications on your contact list. Probably it would make sense to select per contact or group of contacts a profile to see. But what happens if you get a contact request? this probably was issued from one of your profiles and the question might be how to handle this. So having some use cases to start thinking about all the implications might indeed be a good thing.
-- Christian
> En example ? I work for a Big Computer Company in the US (Profile 1) > but in the same time I am looking to open a Hotel resort in France > (Profile 2) and I do not to mix the Profiles in a single Profile. And > I do not want a DOUBLE DATAPORTABILITY... > Netviber
Another use case...interaction with objects in real life. Think about
Microsoft's
Surface technology. I could blast my portable data from my phone to
a Surface-enabled (or similar tech) table in Las Vegas to have it come
alive
with what I like and give me recommendations on where to go.
On Jan 15, 10:17 am, "Tao Takashi" <tao.taka...@googlemail.com> wrote:
> On Jan 15, 2008 4:51 PM, Opo <netvi...@gmail.com> wrote:
> > Hi,
> > Good work but...
> > You wrote in the beginning: "The data model
> > The main object is a Person. A Person has a profile and contacts"
> > But I am a Person but I want 2, 3 or 4 profiles !! Not one !!
> > 1 is for "public business activities"
> > 2 is for "different business activities"
> > 3 is for "private activities"
> > 4 is ...
> Ah, right, actually I want this myself and many people esp. in Second Life
> want that, too. I missed this when writing it down so feel free to add the
> use cases for that.
> And afaik this should also be possible with some OpenID providers, isn't it?
> Now I wonder if this has any implications on your contact list. Probably it
> would make sense to select per contact or group of contacts a profile to
> see. But what happens if you get a contact request? this probably was issued
> from one of your profiles and the question might be how to handle this. So
> having some use cases to start thinking about all the implications might
> indeed be a good thing.
> -- Christian
> > En example ? I work for a Big Computer Company in the US (Profile 1)
> > but in the same time I am looking to open a Hotel resort in France
> > (Profile 2) and I do not to mix the Profiles in a single Profile. And
> > I do not want a DOUBLE DATAPORTABILITY...
> > Netviber
> And afaik this should also be possible with some OpenID providers, > isn't it?
DY> Sure. With all the OpenID providers I am aware of, you can simply get another account. I do this right now, myself. When I go to an OpenID-enabled site where I want to login in my "work" context, I can use the OpenID URL associated with my employer, http:// blogs.voxeo.com/ , because I've enabled that site to be an OpenID provider. When I want to login to a site in my "personal" context, I can use the OpenID URL http://www.danyork.com/ . In my case, it's two sites with which I'm associated, but it could as easily be two accounts and an OpenID provider (or from two different OpenID providers). The challenge, of course, is that now I've got two different logins, passwords, etc.
DY> In my *ideal* world, though, I would have one digital identity but could expose different profiles with different information based on the context in which I was connecting. So something like "www.danyork.com/work/" and "www.danyork.com/personal" or "work.danyork.com" or something like that. I only login once, but then can choose (perhaps by the URL I gave) which profile to expose.
> Now I wonder if this has any implications on your contact list. > Probably it would make sense to select per contact or group of > contacts a profile to see. But what happens if you get a contact > request? this probably was issued from one of your profiles and the > question might be how to handle this. So having some use cases to > start thinking about all the implications might indeed be a good > thing.
DY> Yes, I would want to differentiate. Plaxo makes a start with this. When you get a contact request you can choose whether they are Business, Family or Friend. Each can conceivably see different sets of information about you. (I'm not sure how far Plaxo takes this.) But yes, I would want to designate the profile someone sees. (And would want an arbitrary number of profiles because while I may only want two, others may only want one and others may want five.)
> DY> Sure. With all the OpenID providers I am aware of, you can simply get > another account. I do this right now, myself. When I go to an > OpenID-enabled site where I want to login in my "work" context, I can use > the OpenID URL associated with my employer, http://blogs.voxeo.com/ , > because I've enabled that site to be an OpenID provider. When I want to > login to a site in my "personal" context, I can use the OpenID URL > http://www.danyork.com/ . In my case, it's two sites with which I'm > associated, but it could as easily be two accounts and an OpenID provider > (or from two different OpenID providers). The challenge, of course, is that > now I've got two different logins, passwords, etc.
> DY> In my *ideal* world, though, I would have one digital identity but > could expose different profiles with different information based on the > context in which I was connecting. So something like " > www.danyork.com/work/" and "www.danyork.com/personal" or " > work.danyork.com" or something like that. I only login once, but then can > choose (perhaps by the URL I gave) which profile to expose.
That would be my idea, too. But then it gets difficult to identify you on other websites. Take Second Life: Many people do not want to reveal who they are in Real Life so this would mean for them that they might need different OpenIDs because these are right now the most discussed candidates for identification. In the SL Architecture Working Group there also was some talk about this regarding using different alt accounts with one login. In-world you would show up as the choose alt avatar. This is the same for many games such as Battlefield or Tabula Rasa (although in the latter they all have the same lastname).
Now I wonder if this has any implications on your contact list. Probably it would make sense to select per contact or group of contacts a profile to see. But what happens if you get a contact request? this probably was issued from one of your profiles and the question might be how to handle this. So having some use cases to start thinking about all the implications might indeed be a good thing.
DY> Yes, I would want to differentiate. Plaxo makes a start with this.
> When you get a contact request you can choose whether they are Business, > Family or Friend. Each can conceivably see different sets of information > about you. (I'm not sure how far Plaxo takes this.) But yes, I would want to > designate the profile someone sees. (And would want an arbitrary number of > profiles because while I may only want two, others may only want one and > others may want five.)
True. So I think I need to draw some diagram soon to get my thoughts clear on that ;-) But what we would have is:
- one login - multiple profiles / identities - each profile has a contact list attached. If somebody sees this identity on a website (say Facebook) they can only see the (public) contacts of that identity - on each profile I can define which parts are visible to which group of people (or individual). Groups can be family, friends, enemies etc.
Some questions on this:
- should it be possible to define on which social networks I want to show up as a contact? E.g. Joe has me as a contact and says his contacts are all publically visible. Now I don't want this, even my name is secret. Should I be able to prevent this? - can the one login, multiple identities be done on the OpenID provider side? I guess so unless the OpenID is actually used for identification.
I thought I have more but that's it for late evening ;-)
In the Higgins project this is exactly the approach we're taking. One OpenID with multiple profiles "underneath."
[In Higgins these profiles are called i-cards and there's an open source browser-integrated app called an identity selector that let's you edit them, share them with others, synchronize them with silos like Facebook, HR directories, etc.]
-Paul
Dan York wrote:
<snip>
DY> In my *ideal* world, though, I would have one digital identity but could expose different profiles with different information based on the context in which I was connecting. So something like "www.danyork.com/work/" and "www.danyork.com/personal" or "work.danyork.com" or something like that. I only login once, but then can choose (perhaps by the URL I gave) which profile to expose.
DY> In my *ideal* world, though, I would have one digital identity but could expose different profiles with different information based on the context in which I was connecting. So something like " www.danyork.com/work/" and "www.danyork.com/personal" or " work.danyork.com <http://work.danyork.com> " or something like that. I only login once, but then can choose (perhaps by the URL I gave) which profile to expose.
That would be my idea, too. But then it gets difficult to identify you on other websites.
Take Second Life: Many people do not want to reveal who they are in Real Life so this would mean for them that they might need different OpenIDs because these are right now the most discussed candidates for identification. In the SL Architecture Working Group there also was some talk about this regarding using different alt accounts with one login. In-world you would show up as the choose alt avatar. This is the same for many games such as Battlefield or Tabula Rasa (although in the latter they all have the same lastname).
This problem is solved by using a particular kind of OpenID, namely, i-names. They are based on XRIs that can be resolved in such a way that they drill into the SL silo and identify a particular alt in SL. I've had a number of conversations with the previous CTO of SL about this. It is all doable.
To me that's what data *portability* is about: porting information
from one place to another...
I'd say "identity" is a term that relates to a "place", ie a website
(or a group, as with MS Passport) where I maintain some profile data.
I have several identities/profiles as in, say:
- work
- family
- friends
- camera club
There might be a lot of overlap in there too: I might be working with
my brother, for example.
I want to manage this complexity, and this will be the main
attractiveness of DataPortability to general users: a central
repository from where they can sync their various profiles.
This should apply to my contacts too: if I happen to know of two
identities of a contact, I should be able to make the connection in my
contacts list.
What do we have?
- My Data repository : things that people should know about me, based
on relationship with me.
- My contexts : for each identity, a relationship level (so DP can
sync the data that makes sense to)
- My contacts : id, relationship level, and list of identities (so DP
can merge data from known identities)
This way, viewed from my DP repository, I have a synthetic view of the
information I share and also, for each contact, a synthetic view of
the all the information I'm made aware of.
The tricky bit is in making "relationship levels" management flexible
enough while staying at the no-brainer level...
On Jan 15, 11:58 pm, "Paul Trevithick" <ptrevith...@gmail.com> wrote:
> DY> In my *ideal* world, though, I would have one digital identity but could
> expose different profiles with different information based on the context in
> which I was connecting. So something like "www.danyork.com/work/" and
> "www.danyork.com/personal" or " work.danyork.com <http://work.danyork.com>
> " or something like that. I only login once, but then can choose (perhaps
> by the URL I gave) which profile to expose.
> That would be my idea, too. But then it gets difficult to identify you on
> other websites.
> Take Second Life: Many people do not want to reveal who they are in Real
> Life so this would mean for them that they might need different OpenIDs
> because these are right now the most discussed candidates for
> identification. In the SL Architecture Working Group there also was some
> talk about this regarding using different alt accounts with one login.
> In-world you would show up as the choose alt avatar. This is the same for
> many games such as Battlefield or Tabula Rasa (although in the latter they
> all have the same lastname).
> This problem is solved by using a particular kind of OpenID, namely,
> i-names. They are based on XRIs that can be resolved in such a way that they
> drill into the SL silo and identify a particular alt in SL. I've had a
> number of conversations with the previous CTO of SL about this. It is all
> doable.
My personal take in the interest of simplicity it might be best leave
the functionality of 'Identity Profiles' to multiple OpenID accounts.
I think this is separate and distinct issue from 'Relationship Types'.
Consider that if XFN is going to be our recommended file format for a
list of friends (is it?) , the rel attribute seems to be fairly
flexible, almost like tags.
The question then is how to apply permissions to the tags?
This is probably going to open a can of worms with FOAF vs XFN. But
that should probably be another thread!
Chris
On Jan 16, 9:00 pm, jmuffat <jmuf...@webphotomag.com> wrote:
> To me that's what data *portability* is about: porting information
> from one place to another...
> I'd say "identity" is a term that relates to a "place", ie a website
> (or a group, as with MS Passport) where I maintain some profile data.
> I have several identities/profiles as in, say:
> - work
> - family
> - friends
> - camera club
> There might be a lot of overlap in there too: I might be working with
> my brother, for example.
> I want to manage this complexity, and this will be the main
> attractiveness of DataPortability to general users: a central
> repository from where they can sync their various profiles.
> This should apply to my contacts too: if I happen to know of two
> identities of a contact, I should be able to make the connection in my
> contacts list.
> What do we have?
> - My Data repository : things that people should know about me, based
> on relationship with me.
> - My contexts : for each identity, a relationship level (so DP can
> sync the data that makes sense to)
> - My contacts : id, relationship level, and list of identities (so DP
> can merge data from known identities)
> This way, viewed from my DP repository, I have a synthetic view of the
> information I share and also, for each contact, a synthetic view of
> the all the information I'm made aware of.
> The tricky bit is in making "relationship levels" management flexible
> enough while staying at the no-brainer level...
> On Jan 15, 11:58 pm, "Paul Trevithick" <ptrevith...@gmail.com> wrote:
> > Takashi wrote:
> > <snip>
> > DY> In my *ideal* world, though, I would have one digital identity but could
> > expose different profiles with different information based on the context in
> > which I was connecting. So something like "www.danyork.com/work/" and
> > "www.danyork.com/personal" or " work.danyork.com <http://work.danyork.com>
> > " or something like that. I only login once, but then can choose (perhaps
> > by the URL I gave) which profile to expose.
> > That would be my idea, too. But then it gets difficult to identify you on
> > other websites.
> > Take Second Life: Many people do not want to reveal who they are in Real
> > Life so this would mean for them that they might need different OpenIDs
> > because these are right now the most discussed candidates for
> > identification. In the SL Architecture Working Group there also was some
> > talk about this regarding using different alt accounts with one login.
> > In-world you would show up as the choose alt avatar. This is the same for
> > many games such as Battlefield or Tabula Rasa (although in the latter they
> > all have the same lastname).
> > This problem is solved by using a particular kind of OpenID, namely,
> > i-names. They are based on XRIs that can be resolved in such a way that they
> > drill into the SL silo and identify a particular alt in SL. I've had a
> > number of conversations with the previous CTO of SL about this. It is all
> > doable.
I have been reading from the sidelines and thought it was time to join in. I am a Technical Architect with Target Corp. I have an interest in Social Software and Service based applications. I have a backround in CRM and Integration. I have done work in the areas you have been discussing regarding profiles and user ids.
I am finding the discussion very interesting.
Some questions on this: - should it be possible to define on which social networks I want to show up as a contact? E.g. Joe has me as a contact and says his contacts are all publically visible. Now I don't want this, even my name is secret. Should I be able to prevent this?
I believe this is very important. No one should be able to publish my information unless I give them permission to do so. At a minimum this should be at the profile level, but it might be nice to be more granular. So I control what information of mine others can publish.
- can the one login, multiple identities be done on the OpenID provider side? I guess so unless the OpenID is actually used for identification.
I have not done alot with OpenID but I'm getting into the details. I like the Idea of multiple profiles with multiple permission settings. It might be nice when exploring new sites to use a shell profile with minimal information. Then be able to switch which profile your using once you decide to pursue the site further.
On Jan 16, 2008 12:17 PM, Chris Saad <chris.s...@gmail.com> wrote:
> My personal take in the interest of simplicity it might be best leave > the functionality of 'Identity Profiles' to multiple OpenID accounts.
> I think this is separate and distinct issue from 'Relationship Types'. > Consider that if XFN is going to be our recommended file format for a > list of friends (is it?) , the rel attribute seems to be fairly > flexible, almost like tags.
But aren't the tags in XFN fixed? I would go more for a folksonomy here as I might have different tags than you have. Not sure about which format to use though. XFN seems to me more like a way to mark up things which are on a human readable web page anyway. In our case we might not need the human readable part that much so it also could be FOAF probably. Maybe it also doesn't matter, both formats are more or less easily produced and parsed.
The question then is how to apply permissions to the tags?
Here the question is if these tags and permissions really need to be exposed. It depends on how data portability actually should work. Should Social Network (SN) X simply contact my profile repository (with identification of course so I know who of my contacts is requesting data) my repository could simply just return that data I want to have exported to that contact. So it would be implementation specific and the implementation could create groups or tags as it wishes. Of course it's different if we say that this data also needs to be exportable to a different repository (which we probably should say ;-) ).
This is probably going to open a can of worms with FOAF vs XFN. But
> that should probably be another thread!
Ok, please somebody open another thread of cou want to comment on my comment above ;-)
On Jan 16, 2008 12:54 PM, Sal DiStefano <sal.distef...@gmail.com> wrote:
> Some questions on this: > - should it be possible to define on which social networks I want to show > up as a contact? E.g. Joe has me as a contact and says his contacts are > all publically visible. Now I don't want this, even my name is secret. > Should I be able to prevent this?
> I believe this is very important. No one should be able to publish my > information unless I give them permission to do so. At a minimum this should > be at the profile level, but it might be nice to be more granular. So I > control what information of mine others can publish.
The main statement by some students was probably "Friends don't scrape friends" which hints that maybe another permission might be needed to define if it is allowed to export that data (or which part of that data).
So this would mean that indeed the social network requesting data also needs to know about the permissions. And here I am not sure if this can be done with existing standards. Or will we go the simple route and just say all or nothing for each contact?
> This is probably going to open a can of worms with FOAF vs XFN. But > that should probably be another thread!
FOAF vs XFN, and then RDF vs Microformats, and then ..... It is really about what one try to archive. But the question then become: why such versus fights?
Personally I have no problem with microformats: I convert all of them in RDF using some related ontologies and then I start using the data. So, why FOAF vs XFN? I am really not sure it is the kind of things that should start here, it would be too unproductive for the benefits of this. If I put FOAF data using RDFa in my xhtml, then one can convert it in microformat if he prefers this. I don't care.
Personally I prefer having has much flexibility as possible when come the time to manipulate data. But who I am to say what my fellow prefers?
Subj: [DataPortability-Public] Re: Discussion sur use-cases Date: Wed Jan 16, 2008 7:06 am Size: 764 bytes To: dataportability-public@googlegroups.com
Hi,
I will re-ask one of my previous questions: > I'd say "identity" is a term that relates to a "place", ie a website > (or a group, as with MS Passport) where I maintain some profile data.
Is DP really just about managing users and people profiles?
How about a separate table with 3 or 4 or maybe 5 level of privacy
where the user can define the level of privacy:
You could then pick your level of privacy you want when registering to
a new network while keeping the same user ID but use different
nicknames. That still saves you to enter all the same information
again and again. It is just a basic data normalization process. You
can then move your data around and just select the level of privacy.
It is a fact that 75% of you associates will have moved around in the
next 3 years or so. While they might or might not stay in the same
context you originally met with them, they might or might not stay in
touch while you wish you would.
I will work at developing a model and hopefuly within a week I will
share with you.
> You wrote in the beginning: "The data model
> The main object is a Person. A Person has a profile and contacts"
> But I am a Person but I want 2, 3 or 4 profiles !! Not one !!
> 1 is for "public business activities"
> 2 is for "different business activities"
> 3 is for "private activities"
> 4 is ...
> En example ? I work for a Big Computer Company in the US (Profile 1)
> but in the same time I am looking to open a Hotel resort in France
> (Profile 2) and I do not to mix the Profiles in a single Profile. And
> I do not want a DOUBLE DATAPORTABILITY...
> Netviber
> DP has many areas of concern depending on your perspective. It's not just about any one of these thing but how each of them can effect the other.
Exactly what I wanted to ear. However, this mean one thing: the exploration process will have to be defined (because I think that it is really what people are doing atm: exploring). So, will the exploration will be bottom-up or top-down? What defines the exploration process: to domains of explorations (rights, permissions, sharing, discovery, accessibility, etc). And so on. The group can fire at all directions, but some plans will have to be written sooner then later.
Agreed Frederick - it's almost like we need a curator to information
architect the pages and fill them in as consensus is reached - and
change them as improvements are suggested.
Chris
On Jan 17, 4:54 am, Frederick Giasson <f...@fgiasson.com> wrote:
> > DP has many areas of concern depending on your perspective. It's not just about any one of these thing but how each of them can effect the other.
> Exactly what I wanted to ear. However, this mean one thing: the
> exploration process will have to be defined (because I think that it is
> really what people are doing atm: exploring). So, will the exploration
> will be bottom-up or top-down? What defines the exploration process: to
> domains of explorations (rights, permissions, sharing, discovery,
> accessibility, etc). And so on. The group can fire at all directions,
> but some plans will have to be written sooner then later.
Perhaps the curator function would be a good use of the new Evangelist
Action Group. I see the clear formalization and articulation of ideas
like this as being core to that mission.
Basically, the easier it is for new folks to get up to speed with the
current state, the more effectively the DP concepts will be adopted.
I'll ping the other members and see what they think about taking this
on.
One brick at a time,
Trent
On Jan 16, 6:27 pm, Chris Saad <chris.s...@gmail.com> wrote:
> Agreed Frederick - it's almost like we need a curator to information
> architect the pages and fill them in as consensus is reached - and
> change them as improvements are suggested.
> Chris
> On Jan 17, 4:54 am, Frederick Giasson <f...@fgiasson.com> wrote:
> > Hi Sal,
> > > DP has many areas of concern depending on your perspective. It's not just about any one of these thing but how each of them can effect the other.
> > Exactly what I wanted to ear. However, this mean one thing: the
> > exploration process will have to be defined (because I think that it is
> > really what people are doing atm: exploring). So, will the exploration
> > will be bottom-up or top-down? What defines the exploration process: to
> > domains of explorations (rights, permissions, sharing, discovery,
> > accessibility, etc). And so on. The group can fire at all directions,
> > but some plans will have to be written sooner then later.
> Perhaps the curator function would be a good use of the new Evangelist > Action Group. I see the clear formalization and articulation of ideas > like this as being core to that mission.
Certainly.
> Basically, the easier it is for new folks to get up to speed with the > current state, the more effectively the DP concepts will be adopted.
No doubts about that. Political campaigns are win with one, easy to understand, sentence. Bill Clinton's was, what, "It's economy, stupid"?
People understood what it means, at that time, given what was happening in the USA in 1992. Then he won the presidential.
So yeah, you are right.
> I'll ping the other members and see what they think about taking this > on.
"Christian Scholz (mrtopf.de)" <tao.taka...@googlemail.com> Mon, 14 Jan 2008 10:09:25
>As I thought it might make sense to define the problem field before we >look for solutioins I posted a list of possible use cases to my blog >yesterday (http://mrtopf.de/blog/web20/use-cases-for-portable-social- >networks/). Chris then asked me to put this on the use case page which >I did now:
I've just been doing some work on expanding and clarifying parts of this. I came across this statement.
"your social graph should only be stored centrally on one server"
Excuse me, but that is just never going to work, is it? The problem is that several of the subsequent use cases seem to assume that this is actually intended. So stripping it out or changing it means changing the sense of several of the following cases.
This is pretty core to what we mean by DataPortability when it's applied to profiles and contact lists (CL). So it really needs to be thrashed out.
What I can imagine, is that websites emerge (like say, Plaxo) who's business goal is managing social graphs for people. I can also imagine open source libraries or applications that people could run to do this themselves, somewhat in the style of OpenID. So perhaps what was actually meant here was that some code could be created to aggregate your personal Contact List. In other words take a copy of all the CLs on all the social web sites you belong to and merge it into one. But you're never going to be able to stop Social websites from building their own private social graphs of their members.
-- Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173 Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433 Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat Never Exceed Vehicle Capacity Load
Anyone have any objection to my going through and breaking out each
suggested Use Case as a separate page as a hierarchy under the current
single page?
My thinking here is that the current page becomes a Table of Contents
describing the overall info, then linking to each of it's "Use Case"
children. These pages, then would describe a separate case.
Basically, this should help us discuss them individually, and also
reference them as needed within the rest of the discussions and
Technical Blueprints (eg. which Use Case they're addressing, etc.)
J. Trent Adams <jtrentad...@gmail.com> Wed, 6 Feb 2008 11:04:12
>Anyone have any objection to my going through and breaking out each >suggested Use Case as a separate page as a hierarchy under the current >single page?
>My thinking here is that the current page becomes a Table of Contents >describing the overall info, then linking to each of it's "Use Case" >children. These pages, then would describe a separate case.
Go for it. One thought though, the big long list of pages on the main page is going to become unmanageable. Perhaps we need to break out groups of them into the associated Action group pages.
-- Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173 Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433 Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat Never Exceed Vehicle Capacity Load
