[sldev] RE: Landmarks and Navigation Update 2008-05-29

Tateru Nino tateru.nino at gmail.com
Fri Jun 6 20:06:39 PDT 2008


Was it not said that the landmarks and navigation project would 
deprecate, then eliminate Top Picks?

Stephany Filimon wrote:
> Hi everyone,
>
> I'm sorry I couldn't reply sooner to this thread. 
>
> I am a member of the search team at LL.  The landmarks project will 
> not affect search (technically) at all.  This is because landmarks are 
> stored as assets (and not in the database) and because asset storage 
> does not touch the Google Search Appliances (GSAs).  The GSAs are 
> physically separate from where assets live.
>
> It's possible that the proposed landmarks changes could, for example, 
> affect residents' willingness to use Top Picks.  Top Picks is, at 
> present, the most important vote for a place and traffic is a strong 
> second.  If residents were to stop or change their usage behavior of 
> Top Picks, for example, then the change in behavior would by extension 
> change search results.  This would be true even if the landmarks 
> project weren't happening, of course - it's just that landmarks 
> changes could inspire some residents to change behavior.
>
> Down the road, I think landmarks *could* serve as a potential new 
> resource for search - but, to be clear, in the current project they 
> are NOT designed to do this.  Later on, though, let's say we have some 
> sort of "favorites designation."  We *could possibly* mine that data 
> as a high-quality designation of what residents think is interesting 
> and use it for search results.
> Again, this is NOT part of the current project plan.  We do NOT think 
> this project will lead to different or better search results. 
>
> Cheers,
>
> Stephany
>
> Ann Otoole wrote:
>> My point is simple.
>>
>> This work can impact search and the impact on search needs to be 
>> explained.
>> Or if it is going to negatively impact something then why use time 
>> discussing things that will not be allowed to happen?
>>
>> More communication is needed. And how this effort can enhance search 
>> would be a great thing. (I.e.; I suspect everything is converted to 
>> html urls for google appliance indexing anyway so how can this new 
>> navigation work help? will the history of teleports finally be 
>> counted as a form of real traffic into and out of a sim? etc. etc.)
>>
>> Don't confuse emotionless straight direct talk with negativism.
>>
>> Thanks.
>>
>> ----- Original Message ----
>> From: Drew Dwi <mink at rizon.net>
>> To: Ann Otoole <missannotoole at yahoo.com>
>> Cc: Sarah Hutchinson <sarah at aucreativegroup.com>; 
>> sldev at lists.secondlife.com
>> Sent: Thursday, June 5, 2008 11:54:52 AM
>> Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29
>>
>> Hi,
>>
>> Hate to poke my head in, but careful reading is required before harsh
>> feedback.
>>
>> Per Kippie's post (you don't get your own email? the name says Sarah 
>> fyi):
>>
>> "With regards to User Picks, we learned that Picks are used for a lot
>> more than just sharing of favorite places. It was decided that until
>> Second Life offer the more social features that Picks have evolved into,
>> that it should be left as is."
>>
>> I don't see how any of the changes listed below affect search.
>>
>> -Drew
>>
>> Ann Otoole wrote:
>> > I previously requested someone look into how this project can impact
>> > search and there were no replies so I will reiterate:
>> >
>> > Profile Picks are part of the new search relevancy. Messing with this
>> > breaks search. An external non LL contracted team cannot be allowed to
>> > work on things that will result in devastation of the economy. How
>> > this can even happen is interesting. Great work and all but who
>> > decided to allow you to potentially erase the SL economy?
>> >
>> > Landmarks were initially listed in the SL blog as being a search
>> > relevance factor. The entire discussion of removing landmarks should
>> > have never happened without a discussion of this factor first.
>> >
>> > My recommendation is for the LL search related team to pay more
>> > attention to protecting their turf and communicating with this
>> > community to ensure everyone understands how this work will or will
>> > not impact the new search.
>> >
>> >
>> > ----- Original Message ----
>> > From: Sarah Hutchinson <sarah at aucreativegroup.com 
>> <mailto:sarah at aucreativegroup.com>>
>> > To: sldev at lists.secondlife.com <mailto:sldev at lists.secondlife.com>
>> > Sent: Thursday, June 5, 2008 11:37:46 AM
>> > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29
>> >
>> > Hello all!
>> >
>> > Thank you so much for your feedback and comments on the Landmarks &
>> > Navigation project. My name is Kippie Friedkin and I'm a member of the
>> > Vectorform team. The team has been watching the threads and taking
>> > into consideration all of your input. We're excited that there has
>> > been so much interest in this project! Working on an open source
>> > project is a great learning experience for us, so we've been careful
>> > to respond with accuracy. Now we'll work on responding with a little
>> > more speed. As we have begun to define the design and functionality,
>> > we're better positioned to understand and discuss the technical issues.
>> >
>> > I thought I'd begin this note with an update on the project - where
>> > we've been, where we are, and where we're going.
>> >
>> > *Where we've been
>> > *The project began with a massive research phase that encompassed
>> > Office Hours discussions, interviews with Residents (both new and
>> > veteran), scouring Second Life blogs, researching resident-created
>> > tools, reviewing other Viewers and a host of web apps.
>> >
>> > During this phase, it was our goal to learn how Residents navigate
>> > in-world and how they create, use, and manage Landmarks. We solicited
>> > feedback on their pain points, ideas, and general comments that
>> > touched on Inventory, Landmarks, navigation, and User Picks.
>> >
>> > At the end of this research phase, we presented our finding to Linden
>> > Lab as well as some initial mockups and wireframes that would satisfy
>> > some of the project goals (as stated on the WIKI) as:
>> >
>> >    *
>> >
>> >      *To create a history of locations visited*, presented in some
>> >      visual fashion, which may include:
>> >
>> >          o
>> >
>> >            Back & forward buttons for teleporting through location
>> >            history
>> >
>> >          o
>> >
>> >            Prominent on-screen affordance for accessing/adding 
>> Landmarks
>> >
>> >    *
>> >
>> >      *To improve the existing, or create a new, system for managing
>> >      Landmarks*, which should support the following:
>> >
>> >          o
>> >
>> >            Sorting, re-ordering
>> >
>> >          o
>> >
>> >            Organizing into folders or similar
>> >
>> >          o
>> >
>> >            Renaming
>> >
>> >          o
>> >
>> >            Sharing
>> >
>> >          o
>> >
>> >            Tagging
>> >
>> >    *
>> >
>> >      *To create a new navigation panel* (ie. the visual container for
>> >      the new UI components)
>> >
>> >          o
>> >
>> >            To provide the ability to hide/show this panel.
>> >
>> > A few other things were investigated and discussed at the project's 
>> onset:
>> >
>> >  1.
>> >
>> >      Removing Landmarks from Inventory, in favor of a new system for
>> >      managing Landmarks.
>> >
>> >  2.
>> >
>> >      Deprecating Picks or finding some way to make sharing Landmarks
>> >      easier.
>> >
>> > Discussions with Residents quickly removed these two items from the
>> > scope of this project.
>> >
>> > Removing Landmarks from the Inventory is an extremely difficult thing
>> > from to do from an implementation perspective. It also means that one
>> > of our project requirements - that of backwards compatibility - was
>> > broken. So it was determined that Landmarks were best left a part of
>> > the Inventory. As noted, there are many ways a Landmark can end up in
>> > one's Inventory, and the pros of Landmarks being left where they are,
>> > very quickly outweighed any cons that currently exist.
>> >
>> > With regards to User Picks, we learned that Picks are used for a lot
>> > more than just sharing of favorite places. It was decided that until
>> > Second Life offer the more social features that Picks have evolved
>> > into, that it should be left as is.
>> >
>> > *Where we are today
>> > *The Vectorform team has spent the past few weeks working on
>> > wireframes and designs for the newly proposed features.
>> >
>> > Based on our research, Resident feedback, and meetings with Linden
>> > Lab, we are building the following features in the Viewer:
>> >
>> >  1.
>> >
>> >      *Navigation Panel*
>> >      The Navigation panel will include forward, back, home and
>> >      history buttons, as well as an address/location text box and
>> >      'go' button.
>> >
>> >      The designs are being revised and updated to fit more into the
>> >      new Dazzle style with insight and feedback from Residents and
>> >      Lindens.
>> >
>> >      The Navigation Panel can be able to be shown or hidden using
>> >      both a small toggle at the top-left of the Viewer as well a
>> >      keyboard shortcut - "/". (We are still determining if this will
>> >      work as a shortcut key, but an initial review indicated it was
>> >      not being used by another UI element - so this is TBD).
>> >
>> >      In between the back and forward buttons will be a small, history
>> >      button which will allow a Resident to view the list of places
>> >      he/she has visited during that session. The number of places
>> >      stored in this history and whether it persists between sessions
>> >      can be set in ones User Preferences.
>> >
>> >      The name of the parcel and region will be shown in the location
>> >      history. Mousing over an item in the list will reveal additional
>> >      info (SLURL? How long ago you were there?)
>> >
>> >      Clicking the back or forward button will automatically teleport
>> >      the Resident back/foward in their location history.
>> >
>> >      Clicking the home button will teleport the Resident back to
>> >      his/her home location.
>> >
>> >      Address Bar - The address bar will display a SLURL by default.
>> >      Users can enter a SLURL,  or Region name in their Inventory. If
>> >      the Resident types in a Region name that is not in their
>> >      Inventory, we will go a global search to find the location. If
>> >      the location cannot be found, the Search floater will open.
>> >
>> >  2.
>> >
>> >      *User Preferences
>> >      *We are introducing a new tab to the User Preferences floater
>> >      that will providing users the ability to:
>> >
>> >          *
>> >
>> >            Set the number of days to store location history
>> >
>> >          *
>> >
>> >            Set the number of days to store address bar history
>> >
>> >          *
>> >
>> >            Clear the history of either of the above two items
>> >
>> >          *
>> >
>> >            Export Landmarks in HTML, TXT, or XML formats
>> >
>> >  3.
>> >
>> >      *Create/Edit Landmarks UI*
>> >      Residents will now be able to add a custom name and stores notes
>> >      when creating or editing a Landmark. There will also be the
>> >      option to select or create a folder when creating/editing
>> >      Landmarks.
>> >
>> >      All Landmarks and their folders will be will be placed into the
>> >      Landmarks folder in the Inventory floater.
>> >
>> >      To clear up any confusion, the following circumstances will
>> >      still apply:
>> >
>> >          *
>> >
>> >            Landmarks received from purchased objects will remain with
>> >            the object/folder as they are created.
>> >
>> >          *
>> >
>> >            Landmarks received view Inventory transfer will be placed
>> >            into a Received Landmarks folder by default, but also
>> >            allow for the Resident to edit and select a folder in
>> >            which to place the Landmark.
>> >
>> >          *
>> >
>> >            Landmarks received via automatic givers will also be
>> >            placed into the Received Landmarks folder, by default.
>> >            Still TBD in terms of scoping, but we'd also like to
>> >            include functionality that allows the Resident to edit and
>> >            select a folder in which to place the Landmark.
>> >
>> >          *
>> >
>> >            Landmarks embedded in Notecards will not see any change in
>> >            functionality. The landmark will remain embedded in the
>> >            Notecard and not accessible except through Notecard access.
>> >
>> >  4.
>> >
>> >      *Landmarks Menu*
>> >      A new 'Landmarks' menu will be added to the top menu of the
>> >      Viewer. The options for this menu are as follows:
>> >
>> >          *
>> >
>> >            Create Landmark
>> >
>> >          *
>> >
>> >            Manage Landmarks
>> >
>> >          *
>> >
>> >            Set Home to Current Location
>> >
>> >          *
>> >
>> >            Teleport Home
>> >
>> >          *
>> >
>> >            Received Landmarks - A sub-folder in the Landmarks folder
>> >            in Inventory where all received Landmarks are stored by
>> >            default.
>> >
>> >          *
>> >
>> >            Recent Places - Displays a list of Landmarks a Resident
>> >            has recented used.
>> >
>> >          *
>> >
>> >            Access to Landmarks located in the Inventory Floater -
>> >            Residents will now have access to Landmarks stored in the
>> >            Landmarks folder of their Inventory via this menu. Any
>> >            sub-folders of the main Landmarks folder will appear in
>> >            this Landmarks menu and be navigable via this menu.
>> >
>> >  5.
>> >
>> >      *Manage Landmarks UI*
>> >      This new UI element is meant to allow residents a filtered via
>> >      of the Inventory, in which to organize and manage (edit/delete)
>> >      Landmarks. It consists of a small floater which will almost look
>> >      like a filter viewed of the Inventory Floater. The Manage
>> >      Landmarks floater will allow Residents to filter Landmarks,
>> >      create/edit/delete folders easily, and provide a place (without
>> >      having to weed through the rest of the Inventory) to edit 
>> Landmarks.
>> >
>> >      If you've had a chance to look at the wireframe posted on
>> >      NAV-28, there are two approaches to the Manage Landmarks UI. At
>> >      present, we have been asked to proceed with the separated
>> >      floaters approach (Solution 2).
>> >
>> >      Also, an advanced feature proposed for the Manage Landmarks UI
>> >      was a Data Sort View which would allow Residents to view, sort,
>> >      and manage Landmarks from a column set approach (like iTunes 
>> <http://www.apple.com/itunes/>
>> >      <http://www.apple.com/itunes/>). However, at this time, we have
>> >      been asked to put that feature on hold since it's real benefit
>> >      has not been clear for all project stakeholders.
>> >
>> >      When editing a Landmarks, Residents will have the ability to
>> >      specify a custom name, add their own notes to each Landmark.
>> >      Residents will also have the ability to specify a picture they
>> >      want to use for a particular Landmark. Our technical team is
>> >      also reviewing the possibility of allowing a Resident the option
>> >      of using/reverting back to the default image for this location
>> >      (as specified by the Land Owner). It is as of yet undetermined
>> >      if this feature will be in scope.
>> >
>> >      The Edit Landmarks Floater will include small icons for 'Show on
>> >      Map' and 'Copy SLURL' to provide additional functionality.
>> >
>> >      Finally, we intend to display additional metadata about the
>> >      Landmark from the Edit Landmark floater - date acquired, last
>> >      teleport date, and last updated date.
>> >
>> > *Shared Landmarks & Tagging
>> > *One of our original ideas (and a common suggestion from Residents)
>> > has been to include tagging of Landmarks and other Inventory assets.
>> > We investigated a couple of ways to create a folksonomy use with
>> > Landmarks in Second Life during the first phase of our project.
>> > However, it became clear that tagging functionality would be useful
>> > for many other areas and could touch many other areas including
>> > search, the web, User Picks, and most Inventory items. Rather than
>> > build a small one-off tagging system just for Landmarks, it was
>> > decided that creating a true folksonomy that could be used throughout
>> > Second Life (For searching, sharing landmarks, creating more a social
>> > network, etc.) was a much bigger project than our timeline or project
>> > goals would allow for. So tagging functionality was deemed out of
>> > scope for this project.
>> >
>> > *Where we're going! Issues, Risks, Reviews, and Builds!
>> > *
>> > The design team is working closely with Linden Lab and soliciting
>> > Resident feedback on new designs revisions. We hope to have design
>> > approachs for the new Nav bar solidifed by the end of this week.
>> >
>> > In the meantime, our technical team have been working on laying the
>> > foundation for the new Navigation bar, as well as spending time
>> > researching the items which many of you have spoken about on this
>> > list. A few items for which we're actively researching:
>> >
>> >    *
>> >
>> >      Understanding more about SLURLs and their relation to the Agni
>> >      grid and how they come into play with the beta grid(s).
>> >
>> >    *
>> >
>> >      How the introduction of a new top-left UI element will affect
>> >      Resident-created HUDs.
>> >
>> >    *
>> >
>> >      How the introduction of forward/back button teleport
>> >      functionality will affect grid stability.
>> >
>> > In addition to researching open issues, our tech team is also working
>> > on wrapping up a Viewer build (minus approved creative). We will be
>> > testing that and reviewing it with Linden Lab over the next week.
>> >
>> > I would encourage all of you to continue sharing your thoughts and
>> > feedback. As I stated at the beginning of this message, the Vectorform
>> > team will be much more actively engaged with this list moving forward.
>> >
>> > Best,
>> > Kippie Friedkin
>> >
>> > 
>> ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Click here to unsubscribe or manage your list subscription:
>> > /index.html
>> > 
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>   

-- 
Tateru Nino
http://www.massively.com/



More information about the SLDev mailing list