Note that you'll be able to search for objects in a specific space using the query interface (T8441) independent of any global settings. So you can always explicitly search for stuff in the "Operations" (or whatever else) space, the product question here is just whether we need additional global/default settings to make "switching into a space" an (optionally) more all-consuming operation.

Tossing out an idea, if user has access to more than one space, header - eye turns into a Space switcher? Sampled here with OPS and Security, allowing users to set header color / icon for space.

I really like how that looks.

I'd be slightly worried it might not be obvious that it's a menu, and that I might click it by accident a lot when trying to go home.

I don't really have a good sense yet of how heavy/common/modal switching will be. I could see it being really important/common but I could also see it being rarely used. If it's more on the light/rare side this might be too much UI, but if it's on the heavier side I really like this approach.

Let me see what I can do about the icons, in any case...

I think these are the plausible-ish icons that we aren't using anywhere else yet -- this might be missing icons or have icons we can't really use:

(We're also currently using the icon as both the event default icon and a project icon.)

Maybe we just do like these 12?

After thinking about this, I sort of like reserving some of the more geometric shapes for Badges (T6526), since v1 is probably going to have to use icons.

Maybe Badges gets these:

Then Spaces get these, I guess?

Have you looked at Google's free font icons? Lots of geeky, boring ones in there might be good for spaces or badges without overlapping our current set if that's your concern.

https://github.com/google/material-design-icons

Hmm.. I'm not sure if we'd pick up enough generic/flexible icons to justify adding it. A lot of the icons seem not-generic-enough or duplicated in Font Awesome.

I'm also still not totally sure that we need/want icons. I'm probably going to do a diff where we just use the icon everywhere and see if that looks reasonable or not. If it's better than names, we can go from there.

In T8442#119852, @epriestley wrote:

I'm also still not totally sure that we need/want icons.

Quoting for posterity.

I poked at this a bit, but it doesn't feel great to me, at least with the current header design:

I tried some different colors/spacing/demarcations/etc., too, but couldn't find anything that felt very good.

Maybe worth revisiting after the redesign. I think hiding the default space relieved a lot of the cluttered feeling that having space names everywhere was starting to create. I'm inclined to just stick with names for now, at least until we get enough use that they feel cluttered again.

Tangential, and feel free to ignore if here and now it's not appropriate: in the lines of T6787: Clarify UI for Objects with a non-default Policy, I think it would be useful to have a clear visual cue signaling that you are in a non-public space.

In the newer design, the space name has a red callout so it should be pretty hard to miss. Here's an example on the detail view:

...and the list view:

The policy hint now also shows the stronger of the object and space policies, so it will reflect the actual object scope more accurately in more cases.

Has any progress been made in the last month? Any new decisions on how it should work?

@devurandom, see {I4} if you'd like a personalized status update on this task.

I gather that you still consider the menu-on-eye-icon the best way to present this UI? Would it help you, if I tried to come up with a patch that does exactly that?

I no idea what the end result will be, design wise. I would personally probably re-think the entire header. (20-40 design hours).

So that makes it $3-6k (according to your Paid Prioritization scheme). Which means we'll have to go with a local patch, unless more funders weigh in.

Oh no that's not a "Phacility" quote. I'm just trying to say I really don't know what we'd end up building without a decent effort upfront.

I've got a patch ready, which basically copies the search scope selector implementation, and is still rather crude and unpolished: P1834

It comes with some rough edges:

• The most annoying one is probably that I couldn't quickly figure out how to change the text of the button from within JS (button.value = new_text did not work) - thus I alert() the user instead…
• The next shortcoming is that it does not alter the spacePHID of currently visible AphrontFormPolicyControls. You have to reload the page…
• And finally: It comes with an extremely well crafted UI design: None.

I updated P1834 to fix the mentioned issues:

• The button text is being updated without having to reload the page, after I made two modifications:

$selector = id(new PHUIButtonView())
  ...
  ->setText(
    id(new PHUITextView())
      ->addSigil('global-spaces-dropdown-text')
      ->setText($current_text))

function updateText(button, data, new_text) {
  var text = JX.DOM.find(button, 'span', 'global-spaces-dropdown-text');
  text.innerHTML = new_text;
}

• All visible AphrontFormPolicyControls are being updated, after adding following snippet to updateValue():

var spaceSelectControlKnobs = document.getElementsByClassName('aphront-space-select-control-knob');
for (var ii = 0; ii < spaceSelectControlKnobs.length; ii++) {
  spaceSelectControlKnobs[ii].value = spec.value;
}

• After learning about PHUITextView, and using that instead of raw text, the button looks a little bit better.

The patch could still need a bit of polishing, but should I already submit a review request anyway, so it becomes easier to discuss necessary changes?

From my experience playing with this and some user feedback:

• Spaces would greatly benefit from having colours and icons. Then not only could the selector show different (and hopefully more obvious) icons, but the header (or site background) colour could also be changed to the colour of the space. A less intrusive coloured line below the header, possibly combined with coloured text in the spaces selector, would also be fine.
• The benefit that this small patch alone does to UX feels immense. Instead of having to adjust spaces for each and every object I create (which actually reduces usability instead of increasing it), I can switch "modes" or "projects" globally, which means a lot if your instance contains objects from very different projects which are being worked on by distinct groups of people.
• User feedback suggests that the position (central header) and combination with a text (space name) improves usability of spaces a lot and makes it very obvious which space one is currently working in.
• Filtering the page contents to show only objects in the currently selected space might help users switching over from Redmine (which is the majority in our case) to understand the concept.

Thanks, that feedback is helpful.

I'm currently planning to wait for a bit more adoption/feedback before taking another serious look at this. Any menu-based implementation probably depends on T8918, and we may need to coordinate around menu-design plans for that.

Some feedback from our Phabricator instance. At the moment, the way we have been testing usage of Spaces is:

• S 1: Public (Default). Our open-source projects go there.
• S 2: Internal. Visible only to employees. For this, we would really, really like some way to batch assign/add users to a Policy/Space, as discussed in T9780 and T4103#145539. Handling this manually quickly becomes impractical with large numbers of employees.
• S 3+: Long-running special interest projects. They do exist, and they tend to value their privacy.

To address the three questions further up based on our experiences/user feedback (in reverse order):

This feature would be a huge boon for us, as it would fix one of the more common complaints I'm hearing at the moment; i.e. the tediousness of creating tasks that don't belong in the public space (as well as the not insignificant risk that people forget to set the permissions correctly). I would say yes - we definitely need to be able to switch the default space.

Regarding switching between spaces, that is very individual. But the way we use it, there are (unfortunately) a few users who would probably need to switch between Spaces on a daily basis (at least the feature seems to be envisioned here). Still better than the current situation, where they have to constantly remember to set permissions on each object they work with.

I can't personally imagine that hiding objects would be all that useful. Some users do complain about information overload from Phabricator, but I feel that this is more an issue of fine-tuning individual e-mail preferences and dashboards, than a matter for Spaces.

Just to add: in a big organizations Spaces can be used to divide different legal entities in a group (or big departments).
With this use most probably the majority of the users will belong just to one space, and they will just see the (default) "public" space and their own one. That means that in this case the majority of the users will not even need the switch, but just the possibility to configure the default space for new objects to their own one (not the default "public" space).
The user configurable parameter for the default space for the new objects creation can be anyway a first step in implementing then the full functionality of Space switching.