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

Ann Otoole missannotoole at yahoo.com
Thu Jun 5 09:11:52 PDT 2008


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>
> To: 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/>). 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
>  


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/968d705d/attachment-0001.htm


More information about the SLDev mailing list