Talk:Landmarks and Navigation Project

From Second Life Wiki
Revision as of 05:23, 9 November 2009 by Melissa Yeuxdoux (talk | contribs) (listed some drawbacks of current landmarks)
Jump to navigation Jump to search for SL

Why start with a outdated bookmark model that doesn't scale properly after many years of use. Most people that I know have so many bookmarks in their browser that they stopped using them. Wouldn't it be better to just start with a tagging model at the heart of this, instead of shoving that of as some future feature?

Tags make searching for land/book marks much easier, specifically when you made them long ago and don't remember the exact name of the place, but do know it was a shop that sold red shoes and umbrellas. And lets remember bookmarks are used for storing place you wish to find on a later date, shouldn't you use the best system that helps people find things?

I don't know (yet) if there is any opensource bookmark tagging software, but I really think that should be looked into. That way most of the development can be offloaded to web devs, and api's could be created for people to create plugins for social networking sites, blogs, etc.

You could also opt to use as the place where landmarks are saved, but that would make us depended on their service, which doesn't have to be a bad thing. Or see if LL can buy a license of their software and neatly hook it up with Second Life. (Or any other bookmark tagging service can be used)

Frans 10:50, 23 April 2008 (PDT)

1. Move landmarks out of inventory? No! Landmarks as inventory items that can be passed around is a powerful metaphor.

2. Deprecate picks? Picks are my "home page" (no, I'm not going to put a web home page in my profile ... or use anyone else's ... not until LL provides hosting for it).

3. Extend web search further into SL? Not to replace landmarks, see #1.

4. The #1 thing I want is to be able to limit what landmarks show up in the map landmarks pulldown to the ones in my Landmarks folder, so it doesn't get cluttered up with dozens of duplicate "hi, you bought something at my shop, now I get to spam your map" landmarks.

Argent Stonecutter 04:46, 20 May 2008 (PDT)

Landmarks: "Tradeable assets"

If landmarks are moved out of the inventory altogether (I'm a bit undecided about it; in-world, I tend to pass SLURLs more frequently, since it's far easier to open the map, create a SLURL, and copy & paste it to someone who's waiting for it in IM — to do the same for landmarks would require me to drop everything I'm doing, teleport to the destination, create a landmark, and come back), can we have a simple way of passing them as assets somehow?

They might work like the suggestion above, of course: a way for residents to exchange SLURLs and have them stored "somewhere" (many of us use SL on different locations with different hardware and it's nice to know that landmarks are currently persistent — stored on the grid), and easily loaded back into the client when needed. Sort of like what .Mac does for Safari, Foxmarks for FireFox, or, well, for pretty much any browser.

Gwyneth Llewelyn 07:55, 30 May 2008 (PDT)

Gwyn your own personal use case is never a reason to bork the entire world. There are 1.5 million people here, many of whom don't even know what a SLURL is or can't make or use them but who can handle landmarks. In my experience, people have trouble with the Google-like search much much more than landmarks, and rely on landmarks as a very easy means of travel. You're talking about real-time communications and forgetting how to handle asynchronous communications that are at the heart of the SL experience given the diversity of time zones and countries, enabling people to view sites and interact with each other and trade experience outside of real-time contact.

The issue isn't the "how" of how they are passed as assets; it's assuring that they *will* remain discrete, concrete assets containable and sortable *in both prims and inventory and not just browser boxes*.

Prokofy 6 November 2009

I agree that landmarks as a tradeble assests would be prefered, perhaps the inventory item could be a just a pointer to the landmark in the new landmark system.

Frans 11:56, 31 May 2008 (PDT)

Landmarks & Navigation Project suggestion: Mozilla Weave

Rather than duplicating the body of the message here, I'm merely pasting the link to the mailing list post:
SignpostMarv Martin 08:17, 10 August 2008 (PDT)

Removing Landmarks as Shareable Objects Destroys Socialability and Commerce

This concept of removing landmarks as objects in the inventory -- and in fact removing them as objects in the world -- is all wrong.

Would you *please* stop trying to make this interactive 3-D virtual world "like a web page browser"? It's *not a web page*. It's a *world*.

You will really destroy commerce models already thriving inworld if you remove landmarks as an object that can be put in prims. Every single business in SL uses landmark giver objects onsite or in ads or gives people landmarks as part of their advertising. And that's all good.

The idea that you "can't find or use" the landmarks in inventory is false. Of course you can find them. You use "search inventory" with the name of the store or sim and the landmark is found in the search.

People constantly hand each other landmarks to interesting places precisely because there isn't enough space on the Picks. By putting these "bookmarking" functions into a browser, you remove the sharability. How will I share my landmarks if I can't push them as inventory to other people, individually?!

Again, SL is *not a web page*. It's a 3-D interactive social world that has objects in it that people share and move. Landmarks are one of them. They are sharable sortable objects and inventory access them just fine now.

It's noted in the design description that removing landmarks from the data base will be some kind of "save" for the dbase. Is that what this is all about? It doesn't seem warranted if it kills of interactivity and commerce, exchanging that robustness of socialibility and economic life for a static solo-user's experience of his own bookmarks.

--Prokofy Neva 21:20, 29 September 2008 (PDT)

Uh-oh. The Lindens are back to removing landmarks again as inventoriable user-made shareable content. They want to have "the world like the web" and have instant browser-based transport with one-click travel, they appear to be getting rid of landmarks again. M Linden has indicated this in an interview today in and confirmed it with me when I asked him inworld, and said that browser-based travel would be happening but said there would still be tradeable links. How??? By cut and paste?! The landmark as an object for asynchronous travel outside of browsers but inworld in clickable objects are absolutely vital to commerce and socializing. There is absolutely no reason for this, and if they are fussing about database calls, the Lindens could police through the G-term more of the automatic spam landmark-givers all over now, that are causing clutter in inventories and accidental and excessive use of landmarks, if that is the issue.

A SLURL is not something that can be manipulated with scripts in the same way -- it would mean pasting manually into notecards and I'm not sure a randomizer or serialer script to deliver SLURLs exists or could be made. Currently such scripts have been made to deliver landmarks randomly or in serial fashion.

I have three such objects that all function with a combination of the portal script that pulls up the map with a landmark, and serializer and randomizer scripts. I'll leave aside the hundreds of hours I've spent for years creating and updating these links for travel and socializing in SL to help both newbies and oldbies, and the work that tens of thousands of merchants have done to put landmarks inside stores, rental offices, products, etc. etc. If all those landmarks in world are suddenly deprecated because of a browser solution, it leaves the world deaf, dumb, and blind utterly dependent only on closed friendship networks or groups to deliver links rather than open mechanisms of serendipity, free travel, asynchronous contacts at sites, etc.

--Prokofy Neva 6 November 2009

Do Not Destroy User Generated Content

My mind absolutely boggles at the thought that you would want to get rid of User Picks.

This is *resident content*. *You do not get to destroy resident content*.

Deprecate picks? In favour of landmarks that will be shareable somehow? (when you're going to remove them out of the inventory? and have them shareable as...what exactly? how? off a browser? all of them at once?)

Why? People go to enormous trouble to make their Picks. It's the heart of their identity. I know as a landlord in SL that people record all kinds of special moments as well as places they like on their picks. The picks are *not just places*. The picks are a *story*. The picks have things like descriptions of your best friends. Or your business policies. Or information about using your product.

Could you people *look at how these things are actually used inworld* before you set about destroying them?!

There's no objective need to remove a page off the avatar, used to put his best selection of picks/story pages he wants to tell about his Second Life, in favour of some giant grab bug of landmarks, that does not tell that narrative.

Can you grasp that Picks are not just bookmarked spots, but *a story*? Can you please see this narrative on thousands of people and not tamper with it?!

I fail to see why your need to tinker with the viewer involves destroying what is already established *as user-generated content*. Try to remember that's what it is: *user-generated content*. Linden Lab should not be in the business of "deprecating" *user-generated content* under the guise of "new easier-to-use features".

--Prokofy Neva 21:31, 29 September 2008 (PDT)

Corrected some errors

I've corrected some errors in the (former) "Should we move Landmarks out of inventory?" section (including renaming it); it seems to have been originally written without an accurate knowledge of how landmarks currently work. In particular, Landmarks are not all in one huge list in inventory (this is true only of Landmarks that the user has made himself, and has not moved into other folders), although they are on the currently-useless Map "Landmarks" pulldown, and the names of Landmarks are not useless (they contain the region and parcel name, which is often exactly the right thing). The current inventory provides a powerful way (folders) to sort and organize landmarks, and this was not reflected in the existing "Food for Thought". This being a Wiki, I assume this sort of improvement is okay.  :) -- Dale Innis 06:54, 30 September 2008 (PDT)

Restated idea about Picks

Residents love Picks; talking about "deprecating" them will just anger people (with good reason). What's really being talked about here is better linking Picks and Landmarks. So I've reworded (and renamed) that section to reflect that. -- Dale Innis 07:27, 30 September 2008 (PDT)

Fiddled with "Should we extend Web-type search further into SL? How, and how far?" some too

Just to correct more errors (Landmarks aren't rezzable) and to add a few more obvious thoughts. I'm somewhat concerned that the ideas represented here are some Web-Browser-derived preconceived notions, not very well informed by SL history and Resi expectations. I hope my edits have helped with this somewhat. -- Dale Innis 07:27, 30 September 2008 (PDT)

"To create a new navigation panel" should not be a project goal

New navigation panels, as fun as I'm sure they are to create, are not good in themselves. A new navigation panel should be created only if it actually makes the user experience better. -- Dale Innis 07:34, 30 September 2008 (PDT)

Relevant JIRA

There doesn't seem to be any linkage in this wiki discussion (or article) to the very relevant VWR-7900 issue in the public SL jira. (This was formerly NAV-28.) This shows the outside developer's user interface, though there doesn't seem to be a lot of information about implementation under the covers. :: Latransa Pera 11:14, 30 September 2008 (PDT)

I stuck in a link in the obvious place. -- Dale Innis 11:46, 30 September 2008 (PDT)

Regressed my change to "Food for Thought"

Since someone in a comment on Prokofy's weblog pointed out that there's a June mailinglist posting that obsoletes the entire "Food for Thought" section, this page is apparently not intended as a working document, so I've regressed it to how it used to look, and just added a note and pointers to that mailinglist posting. I think it would be great if someone on the Vectorform team or in LL, or some Resident who's following the relevant mailinglist(s), would keep this page up to date so those of us not as centrally involved could keep up, but I'm not signing up to do that myself! --Dale Innis 07:24, 1 October 2008 (PDT)

Landmarks, affinities, suggestions, and been there done that

A pointer to my post to SL-UX that describes an idea for providing suggestions for places for residents to visit similar to the "customers who bought this also bought..." systems found on commercial web sites.

--Mm Alder 16:35, 9 October 2008 (PDT)

Landmarks Certainly Aren't Perfect As They Stand

Frankly, they're a pain in a lot of ways.

Redundant landmarks accumulate--I wouldn't mind at all if the client told me "You already have a landmark with coordinates within X meters of there--do you REALLY want to clutter your inventory?"

Landmarks become obsolete. You save a landmark because of what's there--if it moves, the landmark is useless. I'd like something that isn't a landmark but a pointer to a landmark. Vendors could hand out these new landmarks and then take the responsibility of updating the underlying landmark if the store/night club/etc. moves, rather than having untold numbers of landmarks suddenly become useless clutter. I wish I had L$1 for every time I looked at someone's picks, thought "gee, that sounds neat--I think I'll go there", clicked, and found myself falling into the sea, or at some store/building/etc. obviously _not_ the one described in the pick. (And if Picks are so darned important, why don't people update them?)

Melissa Yeuxdoux 13:23, 9 November 2009 (UTC)