I thought it would be useful to mention a few point which arose during the Atlas Hop social experience as reported in various places including my summary blog post at http://blog.inf.ed.ac.uk/atate/2017/08/10/sansar-atlas-hop/
Some are noted in other discussion forum posts, bug reports or feature requests and some have been noted as on the Sansar development roadmap already, but I thought it worth mentioning again as part of developing the Sansar social experience.
The Atlas Hop group involved around 15 to 20 from at least 5 countries according to comments made. Users were in Desktop and VR modes and using voice only, text chat only or both. This threw up a number of issues with group communication, sharing destination links as the tour progressed. The modality of use meant people had different tools and information resources available.
1. Desktop users find avatar identification difficult as there is no avatar name id visible and no means to point at or click on an avatar to get such information.
2. The People app does show who is nearby but shows no distance or other means to identify users from the information provided.
3. Avatar mouth animation when they speak is a way to identify users when they are voice active, but the animation is not easily seen from a distance. Some means to identify active speakers (perhaps optionally) via the people app and/or some visible identifier near their avatar (or avatar name) would be helpful.
4b. Your own avatar mouth animation is not active. This is confusing, and is absent as a means to check that your own mic is active and working and being relayed to the system. The users own avatar mouth animation ought to be active.
4b. When asking someone to join as a friend there is no means to add a note to introduce oneself or say why you are asking to join as a friend. Private messages cannot be sent ahead of time until you are friends. hence only open chat is available and visible to all to see such pre invitation communication. That is not appropriate in all cases. A way to add a message to a friend invitation request would be helpful.
5. There ought to be a direct way to interact with a user avatar to get profile information, ask for friendship or send a direct message. As well as vi the nearby people app.
6. At the start of the Atlas Hop we wanted to arrive at an experience "harvest 114" which I have visited before and know by name, etc. But when in the client the Atlas provides no means to quickly find such an experience. It was not conveniently placed to find in the long scroll list of "All Experiences". There is (as yet) no search or way to type in an experience name, and even though I have visited it frequently in the last few weeks I had no means to bookmark it or see it as a recent experience. I had to go out to an external desktop web browser, use the web Atlas, search there and use a click link to have it give the location to the viewer.
7. Web Atlas click links launch the Sansar Updater rather than the Viewer. That is annoying when already in the viewer and simply using the external web Atlas to find and initiate location moves.
8. In nearby text chat in social experiences, users often share locations (which give a "Go" button, Store item URLs, external URLs for other information, etc. The content of the text chat area ought to be easily copied and pasted. It is not clear from the text/keyboard highlighting if copy works there.
9. When moving to another experience, or when entering My Looks (e.g. to add an attachment) the nearby chat is cleared. that is definitely not what we want. It means links, location "Go" items, and so on are all lost to the user at that stage. Others assume they are still visible. This leads to repeated request to type in location information, etc multiple times as users arrive. Nearby chat ought to be persistent from the experience viewpoint of the viewer user. so they see everything they would see from joining to leaving an experience, and its not cleared.
10. In Desktop mode the camera cannot be zoomed well into detailed objects or the faces of avatars. the camera stands too far away to read text on posters or see the voice/mouth animations well. Or even to see items of avatar jewellery that might be being mentioned in social chat.
11. Some discussion of instancing of experiences too place. As noted elsewhere some experiences are suitable for multiple instances, and some definitely are not. A guided tour by a creator of an experience for example might need one instance only and when full that should be relayed to further log in attempts. A classroom with academic tutor should have a single instance. A game environment may be suitable to instance, but even there groups might need a way to ensure they arrive on the same instance. Creators may need a tick box to indicate if a single experience or multiple instancing is intended for their published experience.
12. There was a question on the persistence of changes made in an environment. If it is the case that an experience is not persistent, some clear rules on what changes are visible and when an experience is RESET to its initial state is needed. As in some contexts the change in the environment might be intended to act as a method of communication. E.g. in a classroom prepared to a tutorial session ahead f time, or in an operations room. A way to have persistent and ephemeral experiences may be needed, and a way for the creator to indicate which is their intention in their experience design.
These issues are noted also in my blog post at http://blog.inf.ed.ac.uk/atate/2017/08/10/sansar-atlas-hop/