Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 25036 [details]
The Add Team.. button, which lies to the user
1) Create a single view iOS app solution
2) Right click the project node (not the solution node) and choose options
3) Open iOS Bundle Signing menu item
4) Click "Add Team..."
5) In the new Preferences window that pops up (This must violate a UI guideline. Clicking "Add Team..." should open an "Add Team" dialog or wizard.)
6) Click the (+) button
7) In the "Visual Studio" dialog that arises (UI guidelines, anyone?) enter the Apple credentials and click "Sign in"
Dialog in step 5 is "Add Team," and is actually a dialog for adding teams. Once I've entered my credentials, the team is added.
*()&^% me running. "fastlane not installed" [sic] dialog (Seriously. Are we not even editing UI strings?) with a link to the Fastlane docs. And this AFTER I've entered my credentials
Ignore the misnamed dialogs. Ignore that clicking "Add Team" deep links me into another settings dialog (which I have to explicitly dismiss to continue my work, breaking any 'flow' that could possibly be achieved in VSMac). Ignore that the dialogs are poorly punctuated. Ignore all that.
Focus on this: "Add Team..." communicates an affordance to the end user. It says, "You, the user, can add a team with this." This is the irreducible minimum that must be present if this UI is going to be present. The very first task of a UI is to communicate affordances. Furthermore, accepting the user's credentials (with the attendant anxiety of providing Apple credentials to VS) is an implicit reinforcement of the affordance. It says, "You're on the right track. We wouldn't make you spend the effort if we weren't going to make it pay off." This failure is so basic that it will be universally perceived by our users as outright disdain, and rightly so. Because, it is.
Also, Fastlane requires a paid GH account, IIRC. So, there's that. "Hey, User! We're going to lie to you in the UI and then make you pay someone else in order to use our product. Tell other people how great our tools are, would ya?"
Created attachment 25037 [details]
The final insult, the "fastlane not installed" dialog
The user should never get here.
Version 7.1.5 (build 2)
The link provides details on how to install the fastlane gem on your computer which is a zip and unzips locally to HOME directory.
Thanks for your honest feedback. We're going to work on UX updates of signing interface in 15.6 cycle and some your suggestions definitely can be incorporated to the spec doc.
However, I'd want to clear out before we will move forward.
> This must violate a UI guideline... UI guidelines, anyone?...
Could you specify what UI guidelines are you referring to here (Mac, Windows, something internal, common sense, etc.)? This UI is roughly a 1-1 copy of what Xcode does.
> "fastlane not installed" [sic] dialog (Seriously. Are we not even editing UI strings?)
fastlane guys want "fastlane" to be written in cursive, all lowercase. It's their brand/style/design/etc.
> And this AFTER I've entered my credentials...
Agree, this is fixed already in 15.5.
> Also, Fastlane requires a paid GH account, IIRC
I don't think it's correct. Some fastlane tools need GH private repositories but we don't use any of them in VSfM.
> Focus on this...
Could you expand this idea and suggest how this UI should be changed to clearly communicate our intentions? Just a quick doc with some sketches would give me a better understanding.
As you can probably tell, I became very frustrated when using this workflow.
> fastlane guys want "fastlane" to be written in cursive, all lowercase.
That's a paddling. Millennials are ruining everything.
> This UI is roughly a 1-1 copy of what Xcode does.
I don't want to descend into a deep discussion of UI philosophy, but "copy of...Xcode" is hardly a ringing endorsement. Xcode blows, and Apple's UI expertise is lately in question. (Jobs is dead. Cook is a figurehead. Ive has lost his touch. To wit: The Notch.) One complaint is that, for as long as I can remember at Microsoft, an "Add Team..." button must always spawn an "Add Team" dialog or wizard. Another complaint is that, if fastlane is required, and we're not going to get a wizard, then we _must_ check to see if fastlane is installed and alert the user that fastlane is not installed and ask them if they wish to continue as soon as the Add Team... button is clicked. We certainly _must not_ wait until the user clicks the (+) icon. If the UI the user gets after clicking the (+) icon fails, it should only do so for an external reason, and not one that it really looks like we knew about beforehand. Fastlane is there or it's not. It's our job to guide the user through this. (This may be fixed, as you say. I have not seen the new experience.)
> Could you specify what UI guidelines are you referring to here (Mac, Windows, something internal, common sense, etc.)?
Imagine my horror when a web search revealed to me that this institutional knowledge has been lost to time and attrition. I guess we're left with "common sense." The Add Team... button opened no such thing, but rather a preferences dialog of some kind. Then, another settings dialog was opened at some point in the process. What was disturbing about this is that the settings dialog I started in was modal, and the one I ended up in is also modal. IOW, I could only get to the second one by 1) opening it directly, or 2) some contingent path through the "Add Team..." button. The user will clearly never expect this.
> Could you expand this idea and suggest how this UI should be changed to clearly communicate our intentions?
First of all, thanks for your patience. There are probably externalities that resulted in this UI getting through. Programmer resource restrictions, poor management or PMing, or a complete lack of UI design resources. (Or an institutional hubris that developers and PMs can do UI design. No offense, but they can't.) I'm not a UI designer, either. So, while I can offer input, my feedback is really that of "pissed off user trying to fix an issue with an apparently malevolent UI or organization." The responsibility for designing this experience falls to the organization, and they should really be bringing in UX experts.
That said, these are my (interested layperson) thoughts. "Add Team..." seems like what we're trying to accomplish, but it requires fastlane. If it does, then the "Add Team..." button needs to be visually subordinate to a "Set Up fastlane..." button, and grayed out until fastlane is set up. Or, "Add Team..." needs to open an "Add Team" wizard whose first step checks for fastlane and gates the remainder of work on completing that step. If restarts are necessary, that should be indicated in the wizard.
I have to say, my whole supposition is that "Add Team..." has to do with signing identities. IOW, VS knows about one Apple account, but I want to add another account or team. This is indicative of something that seems really poorly understood in general in our UI: Users don't always get to the UI "fresh." Often, they're taking a stab at solving some other problem and are trying a thing in desperation. Clear indication of affordances, sensible design that doesn't abuse the user's expectations, and concise in-UI help text can go a long way toward, one day, generating some actual good word of mouth about VSMac. We have to find a way to stop jerking users around, especially when they're already frustrated.
Changing this to CONFIRMED. The fix for the bug will be pretty big and include re-design of signing UIs/workflows.
Fixed in version 220.127.116.119 (d15-5)
Author: Oleg Demchenko
Commit: ec524fe5a72928196fc28583f81b8569836aa3bd (xamarin/md-addins)
Included in Commit: a0a9119bc4056463c3780f9597fde5323a7d94e1 (mono/monodevelop)
I'm closing this issue for now. In 15.6 we did a series of updates to improve provisioning UX and fastlane installation workflow.
You can test changes yourself using this build:
In case of any future concerns, I'd prefer to have work with a bunch of smaller issues/bugs. It seems like a more constructive approach to me.