Landmarks and Navigation Project

From Second Life Wiki
Jump to navigation Jump to search
KBwarning.png This article is out of date!
Some features of this project were incorporated into Viewer 2, but the project is no longer active.


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
  • To conduct this project as a public one that better follows open source best practices. This means:
    • Many tasks will be visible in PJIRA. We aren't yet in a position to publish all planned tasks, but you will see many more than we've traditionally published with new projects.
    • Vectorform will check their code into a public branch (that you can check it out of).
    • Weekly project updates will be sent to public email lists like SLDEV, just as they are to internal lists at Linden Lab.
    • Resident participation is not only welcome but strongly encouraged.

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 assessment" 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.)

Project Team

  • Vectorform, a third-party software development company, will complete the design and implementation work for this project, rather than Linden Lab. Vectorform will work closely with Linden Lab, and their team is very familiar with Second Life as residents, Help Island mentors, and developers. You can learn more about Vectorform team members at:

http://www.vectorform.com/secondlife/

Communication and Updates

  • Stephany Linden will email the SLDEV list each Wednesday with project updates.
  • Benjamin Linden's office hour takes place each Thursday at 3 PM (Pacific) in Linden Village - Benjamin Linden🖈. Resident design sessions will be held with Vectorform during the following office hours:
    • Thursday, April 17 (2-4 PM PST, due to scheduling error) - Transcript
    • Thursday, April 24 (3-4 PM PST)

Design Suggestions

Landmarks > New Landmarks menu, in browser-like drop-down style
Creating a new Landmark while standing in a particular place IW
Here is another concept image for the location/back button feature
  • Add "Create Landmark" to the search results window for places - VWR-479

Describes functionality that allows users, when browsing friends' picks, to make one for themselves, then VWR-479 should be reviewed for technical challenges, backward compatibility, etc.

  • Richard Linden has created "A protoype Landmarks menu (that works like your browser's Bookmarks menu)." The prototype still has some bugs, but if we determine that this would be useful we should review this. Here is Richard's mini-spec:
  1. Landmarks menu (priority 1)
    • Add top-level "Landmarks" menu (between World and Tools?)
    • Menu has:
      • "New Landmark..." (which just a new name/location for World > Create Landmark Here)
      • "Organize Landmarks" (which opens up a new Inventory window focused (rooted?) on top-level Landmarks)
      • (separator)
      • items/folders (submenus) based on the top-level Landmarks of your inventory
    • Notes:
      • Should follow the same sort ordering (Name or Date) as your inventory window, so it appears "as expected" to users
      • Make sure to test with torn-off menus (e.g. what happens when you tear off the Landmarks or a submenu, then add/delete Inventory items/folders?)
      • Should only display Landmark-type items in your inventory
    • Questions:
      • Should selecting an item in the menu teleport you immediately? (Like selecting a bookmark) or should it pop open the Landmark Preview floater?
  2. Better "Create Landmark" functionality (priority 2)
    • NOTE: Not sure if we want to do this first-iteration. Should discuss.
    • Lets you [re]name the landmark before it is created
    • Modal, and gives you OK/Cancel
    • Shows a drop-down (tree view?) of subfolders to create the landmark in
  3. FUTURE: Tags, description, share with friends
    • Benjamin Linden has created some mock-ups showing what new navigation UI might look like.

Food for Thought

Note that according to this June 2008 posting from Vectorform, this section is pretty much entirely obsolete, and they are no longer considering moving Landmarks out of inventory, or deprecating Picks.

Should we move Landmarks out of Inventory?

  • If Landmarks stay in Inventory, should we create a separate UI elsewhere (something other than a big long list) for easier management of Landmarks? This would essentially amount to taking what we have and just layering new UI on top of it.
  • Landmarks are currently kept (some might even say hidden) in the 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 residents 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 have their bookmarks/favorites in a (pinnable) side panel.
  • If residents 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. Residents can't use Landmarks in the way in which 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. Residents only get 10 Picks, but the advantage is that other Residents can see them (unlike Landmarks).
  • If residents 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 - without being hasty about this or assuming it's the right/a good decision.
  • Benjamin Linden's mock-ups on this page illustrate an "only share with my Friends" option.
  • We could 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 LL studios.
    • 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.
  • Torley has a lot of good ideas here: "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 (also 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.

Meeting Transcripts

Important mailinglist postings

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Landmarks_and_Navigation_Project&oldid=1141740"