Guild Wars 2

I agree DarkMaster however if you read the previous posts in the Dev forums ANet management made a decision that special links into their site will not be supported. For this reason a manifest is the only way to request any given set of permissions while addressing their concern. Very easy to implement, they just don’t seem to care.

Here is an idea that will work with ANet’s constraint that they don’t want us deep linking in, while at the same time giving us a way to help users choose the correct set of permissions.

Devs would upload an app manifest that specifies their App name, an icon and which permissions the app requires and which are optional. i.e.

<app name=“My Sample GW2 App” iconurl=“http://www.sampleappico.png”>
<permissions>
<required>
<account/>
<characters/>
<inventory/>
</required>
<optional>
<builds/>
</optional>
</permissions>
</app>

Then when users go to their Applications page to create a key…

1) They first pick the app from an auto-complete field

2) Based on the XML manifest for the selected app, the required permissions and optional permissions are indicated for the user to check off. Other permissions are disabled.

3) If the user doesn’t select all the required app permissions the page could display a message to let them know the key won’t work.

This could also provide a means to relate the app name to the key easily since some devs would like that as well.

The work around for not being able to default the permissions would be able to indicate which ones your app considers optional and which ones are required with red text (Requested) or (Required) after the permission name. If they try to create the key without the required permissions the page could alert them that the key will not work with the 3rd party app.

More fundamentally, while the API keys are easy to work with as a dev, the biggest flaw is that end users do not know what an API key is. They don’t know what it means, they think is sounds scary and they do not understand why they are creating one. This is a massive barrier to adoption, compared to a simple OAuth approval flow. I can’t think of any other consumer facing platform that requires end-users to create and give out API keys.

In the end this hurts all the 3rd party devs trying to build enhancements to GW2, because it hampers adoption and creates a huge learning curve for unsuspecting end-users.

Also the copy option has been removed from the API keys page, so now it is really error prone for users to copy the keys

If any dev has created a site using the keys and already has a large user-base (thousands of users) it would be great to hear their real-world experience. If you have created instructions for end users or (API key tutorial videos GASP) that help them through the process it would be great if you could share. My own instructions are several bullet points long and I know that most users will get discouraged.

Everyone has their own play style, I’m sure ANet can see the stats on how many people click vs use hotkeys. I’d wager most players still click. I use both personally situationally. Mousing and clicking is no more difficult than hotkeys (with the exception of the obstructed view).

Totally agree, it seems a simple change that would go a long way for increasing usability. Covering the center of the screen with huge tooltips is a design mistake.

Can you change the behavior of the skill tooltips, by adding a rollover delay (ideally configurable) before they pop up? As a mesmer rolling over any of my shatters completely covers the center of the screen where all the action takes place. It really is a shame because the UI is go great everywhere. Combat involves me looking at tooltips that I’ve seen a million times rather than the enemy in front of me.

I would imagine this is quite a simple thing to adjust and it would add so much to the immersion and usability.

It’s great some people use a Razer Naga, I do, but still prefer a combination of clicks and mouse keys. Most players do not have a Razer and it is a design flaw. If skills weren’t meant to be clicked they should remove that option from the UI, I’m sure that would go over well. Everyone can have their own play style, a good UI can easily support everyone’s needs. The fact that you are not a clicker is meaningless – it is a serious flaw in an otherwise excellent UI.

The tooltips are a real-bummer, scarring an otherwise awesome UI. Please add a configurable hover time. It is disappointing that the main part of the screen is covered constantly.

Any possibility this will ever be addressed?

Passing in a bit mask would be preferred but ANet seems to have ruled that out as they don’t want us direct linked to the GW2 account site. I’m open to anything that will help end users and adoption.

One thing I strongly urge you consider before expanding permissions is a means for 3rd party apps to specify a required set of privileges. As it is, our site has to display lengthy instructions for end users about how to create a key with the appropriate permissions. It is a challenge from the start because our end users don’t even know what API stands for. If privileges expand (as they tend to do), it is going to greatly hinder our growth without a system in place to manage it.

We should be able to set the required permissions for our Apps to help users through the process. There are countless systems that do this today. I know an OAuth type model is out, due to ANet management preferences so how about a manifest model like Google Play, iTunes, Windows App Store, Overwolf etc. etc?

1) We register our Apps with ANet and upload an XML manifest specifying the required permissions.
2) The ANet account key page would have a dropdown that allows the end user to choose the App from a list for which they want to generate a key.
3) ANet processes the manifest and checks the requested permission boxes, making them all read only. (Better yet let the manifest specify Required or Optional permissions)
4) The user can choose to accept or decline. The key is generated the key if they accept, which they can copy it as usual.

This would be a very simple fix, for a major adoption hindrance. The added benefit of this is that ANet can build up a list set of registered 3rd party Apps and track adoption.

We need a way to specify required permissions to allow as many end users to complete the process as possible.

Ideally we could disable it or worst case put a 3 second delay on tooltips. When I roll over my shatters skills the key areas of the center of the screen are covered.

While you are looking at this is would be great if you could provide user feedback after the copy button is pressed. Something like a message that says “Key copied to Clipboard”

Working for me too. Thanks.

Getting the same errors here : ErrBadData

It’s working for me now – thanks!

The APIs have been down for us as well starting around 12:30 am CST ongoing. It’s not a big deal for us now, we are still in development, but hopefully ArenaNet can get a monitoring solution to detect outages.

API is working now!

Anyone else seeing timeout on this API endpoint currently?

https://api.guildwars2.com/v2/account

I’m getting this back…
{"text":"ErrTimeout"}

Also it should say something like “This API key was copied to your clipboard.”

Currently there doesn’t seem to be any feedback.

Great to see progress with the new character API, very useful.

One concern I have since OAuth was removed is that it will be near impossible to instruct ordinary users which permissions they need to add to their API key. This will be especially challenging given the new permissions being added as the API evolves.

Have you given any thought on how to enhance the usability of the API key generation with permissions?

Perhaps it could default to all permissions checked since we can’t pass a parameter of the permissions we require (ideal).

One super minor change I’d like to suggest…BTW I appreciate the streamlining of the New API Key form, removal of the description field, but the text on the page is out of date.

FROM…
Set a name, description, and set of permissions for this key. The name and description fields are for your use. The permissions set which features you’d like this key to grant, and they cannot be modified after key creation.

TO…(something like this)

Create a name and set permissions for this key. The name field is for your use. The permissions control which features you’d like this key to grant, and they cannot be modified after key creation.

I’d be happy not to see the invited ones, so a removing them would be great. Once people found out – it would create guild invite spam if they showed up anyway.

I noticed that the authenticated account api returns guild ids for not-only guilds the user is a member of, but also guilds that they have been invited to and not accepted. Is this behavior by design? If so is there any chance of getting an additional property to indicate this status?

Would you consider removing the description field from the “New Key” form? Removing it will mean one fewer thing that might confuse an end user. Surely a key name would suffice.

I have a few comments/suggestions about the new API key system. My primary concern is user drop-off, I’m sure it is in everyone’s best interest to get users through the API generation process as easily as possible…

1) “API Keys” in the left menu – on the plus side most users will probably be able to locate this menu option. It would be better if it was a red button.

2) Name and description for the API key – IMO will confuse most users, they will think there are specific things they need to enter here and most likely will drop off. If they read the text they might figure it out, but as we know most people won’t bother to read more than a few words. Additionally most people won’t understand why they are creating an API key in the first place.

3) The permissions check box. While not a problem now since there is only one permission (“account”). I can see this as a show stopper after new permissions are added. App developers need a way to request a minimal set of permissions (perhaps by passing ids on the querystring).

4) After the key is generated there needs to be a button to copy it to the clipboard. The key is long and the font is small, so there is a high probability that it will be copied incorrectly.

I understand management made the decision to remove OAuth, but this doesn’t add any extra protection against phishing. Given that, I’m not against API keys as an alternative, but there needs to be a way to streamline API key generation and input.