I can design some UI's if necessary<br>
maybe something with Horror Vacuii..ie: the "evil one"<br>
something that is pretty universa/<br>
Horror Vacuii=represented by eyes all over the face<br>
<br><br><div><span class="gmail_quote">On 7/22/07, <b class="gmail_sendername">Bert Freudenberg</b> <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just to be sure: I assume you are referring to a petname sytem, Eben?<br><br><a href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">http://www.skyhunter.com/marcs/petnames/IntroPetNames.html</a><br><br>I think this is indeed a very nice and simple solution to a hard
<br>problem.<br><br>- Bert -<br><br>On Jul 21, 2007, at 23:21 , Eben Eliason wrote:<br><br>> I, too will need to think in much more depth about this problem. I<br>> know I discussed a few of the implications with Dan as he began
<br>> implementing the PS early on.<br>><br>> From an interaction design perspective, I don't think that it's<br>> necessary to allow name changes (or at least, we don't need to make it<br>> trivial, like changing colors will be). The idea is that children
<br>> will be identified by their given name, and as such I'd rather not<br>> refer to a "nickname", unless we actually make the distinction between<br>> a nickname (changeable) and real name (much less so). This doesn't
<br>> guarantee security, of course, but it does make it harder to<br>> impersonate someone.<br>><br>> Also, we discussed possibilities for what might happen when a child<br>> changes colors, photos, etc. One possibility is that these children
<br>> are rendered slightly differently in the UI, perhaps with a badge. By<br>> clicking on them (or some interaction not yet determined...perhaps for<br>> friends you actually get a notification message) you will be able to
<br>> see the former colors/photo (as stored on your machine) and the new<br>> colors/photo (as provided by them). This would make it rather<br>> difficult for Bob to spoof your friend Alice, assuming that you have
<br>> ever in the past received Bob's identity info, since he would always<br>> have to advertize "I'm Alice, formerly known to you as Bob."<br>><br>> I suppose this would actually be sufficient if we also specially
<br>> identified friends in the UI as well, as you mention, perhaps by<br>> applying a star badge to them. In that case, any friend of yours who<br>> attempts to spoof another friend of yours will be rendered the same,
<br>> but will also initiate an "identity change" message. Any non-friend<br>> of yours - even those you've never seen before - can try as they might<br>> to spoof a friend of yours, but can never have the star badge.
<br>><br>> As another note, when these changes in identity occur, its probably<br>> beneficial for the children to view the "identity change" message<br>> before the interface adjusts the rendering of the XO whose identity
<br>> changed. That way you can find Alice rendered in pink/purple as<br>> you're used to, without being temporarily confused by the fact that<br>> she changed overnight to green/yellow.<br>><br>> As far as unique naming goes, as I mentioned, I'd really prefer to use
<br>> real names. Real names, of course, aren't always unique. I'd like to<br>> use first names only by default, adding the last initial in the<br>> display when first names conflict. Of course, when the last initial
<br>> conflicts, we could use full last names. Beyond that, we're mostly<br>> out of luck, but perhaps that doesn't matter in the general case. If,<br>> however, you want to make two people with identical names your
<br>> friends, the "make friend" process could check the list of current<br>> friends, find the match, and alert you to it, offering to let you<br>> modify the name that you locally use to represent the new friend.
<br>> This has the added bonus that, if an outsider you've never before seen<br>> tries to spoof a friend, and you try to make the outsider your friend<br>> thinking that you accidentally de-friended the person they're
<br>> spoofing, you'll get the duplicate friend message and think twice<br>> about continuing.<br>><br>> - Eben<br>><br>><br>> On 7/21/07, Ivan Krstiæ <<a href="mailto:krstic@solarsail.hcs.harvard.edu">
krstic@solarsail.hcs.harvard.edu</a>> wrote:<br>>> On Jul 21, 2007, at 4:07 PM, Simon McVittie wrote:<br>>>> (Mailing this now while I remember, because this is something we<br>>>> need to<br>>>> think about relatively soon after Trial 2, I think. Daf and I will
<br>>>> be in<br>>>> Boston on Monday, Tuesday and Wednesday trying to debug<br>>>> collaboration, so it'd<br>>>> be great if we could talk to Ivan and Eben about this while we're
<br>>>> there.)<br>>><br>>> I'll read the rest of the message in a bit; can you meet with me at<br>>> 2PM Monday? I'm extremely busy the first three days of next week.<br>>><br>>> --
<br>>> Ivan Krstiæ <<a href="mailto:krstic@solarsail.hcs.harvard.edu">krstic@solarsail.hcs.harvard.edu</a>> | <a href="http://radian.org">http://radian.org</a><br><br><br>_______________________________________________
<br>Sugar mailing list<br><a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a><br><a href="http://lists.laptop.org/listinfo/sugar">http://lists.laptop.org/listinfo/sugar</a><br></blockquote></div><br><br clear="all">
<br>-- <br><a href="mailto:delucks@gmail.com">delucks@gmail.com</a><br>t: 443.614.0518