Here is the latest feedback, from Stephany Linden and Benjamin Linden (yesterday 2008-05-21) based on the files you see here. Subsequent comments from Vectorform (as of this morning 2008-05-22) are in line.

***
On 5/21/08 10:11 PM, <stephany@lindenlab.com> wrote:
Apologies for the somewhat rough nature of these notes... We began w/ the PDF and then moved to the much-more-fun eye candy.

PDF
p.2

• The results attached to the yes/no options are in the wrong order (i.e., the yes result should actually be paired with no and vice versa - just swap 'em).
  • • VF: This will be fixed, sorry for the confusion.
• The "\" is OK to use - we checked.
  • • VF: Perfect.
• We need clarity re: where it says "do nothing": what is meant here?
  • • VF: This simply accounts for the "Is Nav Bar Hidden? - No (after we flip the Yes and No per above)" condition - for when the Nav Bar is accessed via the Keyboard Shortcut ('\"). In other words, the Nav Bar can be toggled from collapsed/closed to visible via the UI toggle (using click or hover, TBD after flash prototypes), but the same is not entirely true for the keyboard shortcut ("/"). If the Nav Bar is hidden, hitting the "/" would expand/unhide the Nav Bar, but if the Nav Bar is visible, hitting the "/" again, will NOT hide it - as this would interfere with typing a SLURL for example.

p. 3-7

• We focused on the alignment issue (comparing left and center)
• We'd LOVE to see this in Flash. Do you need alignment direction from us, or are you doing both in Flash? Let us know.
• We're leaning toward centered.
  • • VF: If you feel very strong about one of the directions, and it seems like this might be the case with the centered solution, we would be perfectly fine with focusing all our energy in prototyping this one option. We are planning to do a click-able prototype and a hover prototype. Do you want us to prototype only the centered, or both the center and left?
• OMG we LOVE Dark Organic best. No question. More on that later. Restraint.
  • • VF: Excellent! We will focus all our design attention moving forward on this design. After we address your additional comments on this from bellow, can we consider this to be the approved design moving forward?

p. 8

• The back button has a list of places to go (a little drop arrow) but the FW button doesn't - is that missing? Please clarify: Should there be a chevron regardless, but should it just be grayed out?
  • • VF: During the onsite meeting, Ben expressed to us that he really likes the IE7 (and Firefox 3) treatment and solution for combining the Back and Forward nav history into one pull down menu. We feel strongly that this is a great idea, because not only it simplifies the UI, but because the Forward nav history (and the Forward button) will, realistically, be significantly less used and as a result somewhat less important (does not really need its own pull down).
      It would be organized like this:
      Region - Parcel - x, y, z
      Region - Parcel - x, y, z
      Region - Parcel - x, y, z
      Region - Parcel - x, y, z
      >> >> Region - Parcel - x, y, z
      Region - Parcel - x, y, z
      Region - Parcel - x, y, z
      Region - Parcel - x, y, z
      Region - Parcel - x, y, z
      The one item that has the arrows is the current location, everything above is Forward Items, everything bellow are Back items. In our designs, the "arrows" are replaced with a treatment which accounts for the entire row being colored. More specifically, the gold color, which we will replace with dark navy, per your request.

p. 12

• Should the drop down show the reformatted slurl format or the original as typed?
• Can you tell we're not sure?
  • • VF: Even tho' any nav field entry will always be reformatted to the SLURL equivalent upon successful teleportation - it is probably best to show the user the original typed entry. The idea is that these entries would trigger the users' memory, in which case it is necessary/best to present the users with their exact input. Let us know if you feel otherwise.

p. 14

• We did not see a design for a bookmark (landmark) tool bar. Have we decided not to do that?
• Are we de-scoping the landmarks tool bar to be only a menu item?
  • • VF: Yes, I believe we decided to not include a landmark button on the nav bar, and we de-prioritized the Favorite Landmarks toolbar and decided to focus only on the Nav Bar.
• If yes, we need a corresponding folder in the drop down.
  • • VF: If we are not doing a Favorite Landmarks toolbar, do we still need a Favorites Folder? In our last meeting, we bounced around the idea of maybe including a Favorites Folder as a first phase, and based on user feedback, and how much use this folder gets, potentially create a corresponding Favorite landmarks toolbar. Do you have info information on this, to make decision as to which direction to proceed with? We believe that it might be best to not include a Favorite Landmarks toolbar, or a Landmarks Icon in the Nav Bar.
• You have #8 marked as menu scroll widget, but we wanted to point out that this actually comes free w/ menus - it's built in for when the menu is too large; scroll happens automatically no need to build anything new there, for anything too large adjusts already.
  • • VF: Thanks for clarifying this.

p. 17

• Will the word "or" be on the page b/t these two buttons? Ben says "no".
  • • VF: the word "or" will be removed.
• We should remove recent places; it should say "landmarks" because that would be the top level menu item or folder (i.e., because recent places is only automatically filled based on where a resident goes; it's not a choice).
  • • VF: That is correct, this is a mistake in wireframe. Will revise.
• #9 - does not support creating nested folders. How do we intend to support that?
  • • VF: Our idea is that this control and functionality will be very similar to the Firefox Add Bookmark control. See screenshot bellow. This will allow the user to add a Landmark at any folder level, as well as create a new folder, from within the same control. With that being said, we might not need a Create New Folder button, as this functionality is covered within this Firefox like control. How does that sound?
      [cid:3294316625_6680845]

p. 18

• How does #4 on p. 18 actually happen? How does uncategorizing or filing a landmark as "uncategorized" work?
  • • VF: Similar to how adding a bookmark in a browser works. In other words, when adding a Landmark, the user will have the option of adding the Landmark into a specific folder or just add it at the top level of the folder hierarchy, in other words, "uncategorized". On page 14 of the pdf, in the Landmarks menu, bottom section, you can see the Landmarks folders and bellow, Landmarks that are not in folders, thus "uncategorized". See screenshot bellow for Firefox equivalent.
      [cid:3294316625_6715368]
• I.e., is uncategorized an actual folder, or
  • • VF: Uncategorized is the top level of the Landmarks folder hierarchy.
• Does choosing uncategorized automatically put the landmark into the top level landmarks folder or similar
  • • VF: Yes, this is what we atempted to explain above in more detail.
• Save/cancel should be right aligned

p. 19

• We want user to be able to select which folder it goes into - don't see how that happens with the flow shown on p. 19.
  • • VF: It is addressed in :
      Resident can enter:
• Name
• Folder to store LM in/Create new Folder
• Notes
  I am hoping some of the other answers above cover this. Let us know if you need additional clarification on this.
• Action for dragging landmark on to an avatar is missing.
  • • VF: We thought we covered it in the "Profile Drop Inventory transfer" flow/schematic, but we can add another entry just for this. After a Visitor accepts a landmark, another idea is to present the user with the Create Landmark floater, which is showed on page 17. The floater could probably be titled, "Add Landmark" or "Add Received Landmark" in this situation - or left as is for consistency. Otherwise, we can stick with the proposed solution outlined in the work-flow, which accounts for a Received Landmarks folder, where all the received landmarks are stored, until the user organizes them at a later time.
      Or it could be an combination of the above. Ex:
      Drop/Drag -> User Accepts -> Floater prompts user to place the Landmark in the default "Received Landmarks" folder or place it (and edit it) somewhere else -> User is presented with the "Add Landmark" floater where the landmark details can be edited and the specific folder can be used or created (per above notes)
      Thoughts?
• We agree w/ adding "create landmark folder" to the place information window (that shows up after you click on a slurl (to your answer ?)).
• RE: the first 2 items on the page. The user is not allowed to choose the folder it goes into w/ these 2, but otherwise the user can choose the folder. Should we be more consistent here? Should we always allow folder choice?
  • • VF: I think we probably should always allow them to decide if they want to choose a folder vs place I in Received Landmarks folder. Yes consistency is very important.

p. 21 - Do we need about landmark AND edit landmark?
— VF: Good point, Edit Landmark is sufficient.

p. 22

• Is the edit landmarks floater the same thing shown on p. 24 or is it a separate window?
  • • VF: Yes, the same floater. Based on your requests, we are working to figure out how the ui would flow and function if this floater is to be divided in two, one floater for the Folders and the other for the Edit Landmark. If this will end up being the final solution, then the floater showed on this page would be the Edit Landmark floater, without the Folders.
• YES to technical q. on p. 22 - yes b/c we do that now (we allow a resi to drag snapshot from inventory onto image). So this is consistent - YES.

p. 22-24

• Do we want to open this whole big window on p. 24 to allow them to just to edit a single landmark?
  • • VF: Yes, In our original opinion/solution we suggested that the landmarks folder and edit landmarks floater would be combined into one window. Per above notes and comments, we are now working on a solution that accounts for these two windows being separated.
• If not, then we think cancel and save have different behaviors based on whether we open the whole manage landmarks window, or just a stand alone window for editing a landmark.
  • • VF: Yes that is correct, it would be different based on having the edit landmark window separate or connected to the folders window/section. To clarify this further, in the scenario where the windows are not separated, Cancel (Delete also) would collapse/close the Edit Landmark Section (similar to the Chat/users functionality Ben pointed out in a previous conversation). The collapse/close feature is not clearly explained in these revised Wireframes. We will make a note of that.
      If the Folders and Edit floaters are separate, Cancel should not close the Edit floater. The close would need to be done via the close icon "x". Additionally, if these two windows are separated - we would need to allow for multiple Landmark Edit windows to be opened at the same time, as it would not be an ideal UX to refresh this same one separated window every time another Landmark is accessed from within the folders floater.
• Re: cancel - if they've opened the whole big window, edited something, and click cancel, it shouldn't close the whole big window BUT it should revert the editing back to the default/prior information - to whatever was there before.
  • • VF: Would the above mentioned solution be better? Cancel would collapse the Edit Landmarks side of the Manage Landmarks UI component.
• Is the edit landmark floater different from manage landmarks window?
  • • VF: It is the same but it refers to the manage landmarks window with the edit landmark section visible.

p.23

• From what this page says a lighter weight edit landmark UI exists somewhere - for ex. on page 23 (in the orange box attached to organize LMs in folders) it says: "Residents can use the Edit Landmark context-menu option from the inventory floater to edit a single LM".
• Where is this edit a single LM shown?
  • • VF: "edit a single LM" refers to the Manage Landmarks windows with the Edit Landmark area visible (not collapsed) - - in 'Folder View' as opposed to "Data Sort View' where multiple landmarks can be managed at the same time.
• Ben and I find it hard to follow the work flow on this page. Can we do a more linear/venn diagram thing for conditions?
  • • VF: This flow diagram, accounts for:

1. The obvious scenario of accessing the the Landmarks Manager window (made of folders and edit area) from the main menu (top of the diagram)
2. The more 'visually' complicated scenario to describe when and why a user would want to have access to the Data Sort View. The confusion, I think, comes from the context-menu blurb which accounts for the fact that a user can access the Manage Landmarks window from the Inventory, via right clicking on a landmark.

In a nutshell We were just trying to build a stronger case for the Data Sort View, which I believe you are very much in favor for.
Sorry for the confusion...

p. 24

• The save/delete/cancel and tp/show on mp/ copy need to be swapped - meaning save/delete/cancel go on the right side
• This page is very busy
• We think we need to somehow split the left folder side from the right/we should split the page.
• We don't want right click in folders to be PRIMARY entry point - but it can exist.
  • • VF: Please clarify what you mean by entry point? Teleport?
• We see benefit of clicking through on left and seeing things change on the right
  • • VF: This is the one thing that we are struggling with at this time too... We also see the great benefit here, but if we are to split these windows, we feel that it would be confusing for the user to have the contents refresh - as mentioned above, it would probably make most sense to allow for multiple edit windows to exist on the screen at the same page - which clutters the screen even more, which at times, makes us question if splitting the windows is indeed the better solution.
• Ben suggests a tabbed design for the right side; he suggests taking "my notes" and making one tab and then taking everything from "description" down (incl. info and location) and making another tab.
• "description" would be first tab/default on tab
  • • VF: We can explore a tabbed design for this, as suggested. However, in our opinion, it is very important for this window to be very similar to the Add Landmark window/floater - for usability and consistency reasons.

p.27
For consistency sake double clicking should TP you in all three cases, those three cases being:
1) inventory
2) folder view
3) manage landmarks
should apply to data grid view also
— VF: Sounds good

p. 28
We need to add an option for users to set preference for setting the default folder when storing received landmarks.
— VF: Yes – Or we can have all landmarks, by default, go in a "Received Landmarks" folder. Do you feel strongly that this should be a user defined preference?

• Stephany hates the different sized buttons (but I love everything else!)
• But Ben thinks the big button it gets at mainline usage, meaning Ben thinks users will click the back button more often and thus it should be bigger.
• Stephany says: "If it must be bigger then there needs to be space, b/c it is too easy to click the other baubles."
  • • VF: See the attached JPG for a design variation with same size buttons.
• Change gold to navy/Dazzle/ dark chat bg color
  • • VF: Sounds good.
• Ben thinks this is dramatically diff from dazzle and wants to tie it in more; Stephany is fine w/ it.
• The pixel width around the nav bar is too much - buttons look OK though.
  • • VF: Can you please clarify this? Is the organic shape to wide, as in, does it extend/tapper to much to the sides?