Landmarks and Navigation Project

Project Goals

This project seeks to improve the following aspects of Second Life:

• Knowing where you want to go
• Knowing where you are now and how to remember it, if you want to
• Knowing where you've been
• Knowing how to return to the places you've been (both very recently and not so recently).

More specific project goals are:

• To create a history of locations visited, presented in some visual fashion, which may include:
  • Back & forward buttons for teleporting through the location history
  • 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:
  • Sorting, re-ordering
  • Organizing into folders or similar
  • Renaming
  • Sharing
  • Tagging

• To create a new navigation panel (i.e., the visual container for the new UI components)
  • To provide the ability to hide/show this panel

Requirements

• Backward compatibility: Everything we do must be backward compatible and seamlessly integrated with the existing system (with all of the scripted objects in IW stores right now, for example). To ensure backward compatibility, conducting a sort of "inventory assessement" on Landmark functionality IW will be necessary.

Dependencies

Though we could conceivably proceed without these, the following two improvements may improve the project's chances of success:

• Improved hyperlink support throughout the client, in which any slurl becomes an active link, for example.
• Improved contextual menu support (i.e., right-clicking on something and getting a list of things to do with it. In Chat History, for example, a user receives a slurl and can right-click on it. If menu support improves, we can add another right-click option like "Add Landmark," etc.)

Design

Landmarks 2.0 is officially part of the Search Milestone 2 (M2) project (<jira>DEV-81</jira>) in Studio Shipley. It will be designed, and only designed, in Q1 2008. Implementation will follow in subsequent quarters.

• If we decide to create functionality that allows users, when browsing friends' picks, to make one for themselves, then <jira>SL-2174</jira> - VWR-479: Create Landmark from Profile Picks should be included in the Q1 2008 design and reviewed for technical challenges, backward compatibility, etc.

<jira>SL-45697</jira> - Search: Promote Landmarks to top level menu

• Add Landmarks menu to top menu, with:
  • New Landmark... which opens floater for creating landmark at the current location
  • Organize Landmarks... which opens floater for organizing - it's an inventory window that shows only Landmark items
  • separator
  • hierarchical display of Landmark items in your inventory

See Landmarking Mockups on Search UI Design

Mockup - Landmarks menu on the top menu bar:

File:Search1.jpg

Mockup - Menu drops down, shows a subtree of your inventory:

Mockup - UI for adding a Landmark:

Prototype - In-progress version of the "Organize Landmarks" floater:

File:OrganizeLandmarks.jpg

Open Issues

• Should we move Landmarks out of Inventory?
• If Landmarks stay in Inventory, should we create a separate UI elsewhere (besides a big long list) for easier management of them (essentially taking what we have and just layering new UI on top of it)?
  • Landmarks are currently kept (some might say hidden) in Inventory in a very long list. List length in itself isn't the problem, but it illustrates that the naming and organization of Landmarks is a problem.
  • Many users already have lots of Landmarks; the menu can be three screen-fulls tall, which is a horrible experience. To address this issue, IE7 (and Firefox 3?) moved to having bookmarks/favorites in a (pinnable) side panel.
  • If users don't rename Landmarks they don't know what they are. Nothing is automatically associated with the Landmark that describes it in a meaningful way.
  • This makes Landmark accessibility more difficult than necessary.
  • Landmarks don't map, Web-metaphorically speaking, to other "places I want to go, places I've been" online behavior, as browser bookmarks do, for example. Users can't use Landmarks in the way they would use other online tools to find, remember, store, and share places.
  • See Ben's early mock-ups on more menu-like UI for Landmarks on this page (above).
  • The UI for managing Landmarks will need to match the new model we design, perhaps taking the form of categories/folders of bookmarks, enabling users to search subsets of bookmarks.
  • Can a technical case be made for saving the database by moving Landmarks out of Inventory? Can we possibly kill more birds with this stone?

• Should we deprecate User Picks? If so, how?
  • Landmarks overlap with User Picks. Users only get 10 Picks, but the advantage is that other Residents can see them (unlike Landmarks).
  • If people could see others' Landmarks via a "public" flag or something similar, Landmarks could serve the same purpose as User Picks.
  • In sum, we should consider getting rid of Picks altogether and making Landmarks shareable.
  • Ben's mock-ups on this page illustrate an "only share with my Friends" option.
  • Consider associating an image with each Landmark. This shouldn't be difficult; often there's already an image that's associated with a parcel.
  • We do something similar today with User Picks. When a user adds a new Pick to his/her profile, it grabs a new image from somewhere that we put in the Picks.

• Should we extend Web-type search further into SL? How, and how far? *
• Change Landmarks from being rezzable objects (that teleport or bring up About Land, for example), to objects in a web db that users access through slurls, and interact with them through the IW browser?
  • This is a web services idea that we'll thoroughly vet with Jeff's studio.
  • Advantages: Reduced db load, reduced client download time (which is also on the list for the First Five Minutes UI project)
  • Drawbacks: Backward compatibility with existing Landmarks may be difficult.
• "If we're going to have a browser it needs to have a back button."
  • Make a Back button for teleports. Create an integrated Back button/bookmarks/location UI.
  • if teleport history is on the table. Since Q1 2008 is all about design, teleport history is up for consideration and vetting.
  • <jira>SL-24061</jira>: We especially like Torley's ideas: "Every time you teleport, a corresponding landmark is saved in a "Recent Places" sub-folder in your Landmarks folder. This info could also be integrated into the World Map..."
  • Advantages (as noted by Torley): "1) it persists between sessions using a storage system which already exists in SL (cutting down on dev time); 2) a sort by Date mode already exists in Inventory so there's no problem viewing it chronologically; 3) you can easily hand out the landmarks if you want to share cool places you've just seen AND 4) it doesn't clutter up your main Landmarks."