{"action":"created","issue":{"url":"https://api.github.com/repos/TechAtNYU/intranet/issues/123","labels_url":"https://api.github.com/repos/TechAtNYU/intranet/issues/123/labels{/name}","comments_url":"https://api.github.com/repos/TechAtNYU/intranet/issues/123/comments","events_url":"https://api.github.com/repos/TechAtNYU/intranet/issues/123/events","html_url":"https://github.com/TechAtNYU/intranet/pull/123","id":99345066,"number":123,"title":"Sort home page resource type cards in ABC order","user":{"login":"ethanresnick","id":471894,"avatar_url":"https://avatars.githubusercontent.com/u/471894?v=3","gravatar_id":"","url":"https://api.github.com/users/ethanresnick","html_url":"https://github.com/ethanresnick","followers_url":"https://api.github.com/users/ethanresnick/followers","following_url":"https://api.github.com/users/ethanresnick/following{/other_user}","gists_url":"https://api.github.com/users/ethanresnick/gists{/gist_id}","starred_url":"https://api.github.com/users/ethanresnick/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ethanresnick/subscriptions","organizations_url":"https://api.github.com/users/ethanresnick/orgs","repos_url":"https://api.github.com/users/ethanresnick/repos","events_url":"https://api.github.com/users/ethanresnick/events{/privacy}","received_events_url":"https://api.github.com/users/ethanresnick/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/TechAtNYU/intranet/labels/in%20progress","name":"in progress","color":"ededed"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-08-06T03:28:32Z","updated_at":"2015-08-11T02:14:05Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/TechAtNYU/intranet/pulls/123","html_url":"https://github.com/TechAtNYU/intranet/pull/123","diff_url":"https://github.com/TechAtNYU/intranet/pull/123.diff","patch_url":"https://github.com/TechAtNYU/intranet/pull/123.patch"},"body":"cc @grungerabbit\r\n\r\n@maxdumas: is this the right place for this?"},"comment":{"url":"https://api.github.com/repos/TechAtNYU/intranet/issues/comments/129679454","html_url":"https://github.com/TechAtNYU/intranet/pull/123#issuecomment-129679454","issue_url":"https://api.github.com/repos/TechAtNYU/intranet/issues/123","id":129679454,"user":{"login":"ethanresnick","id":471894,"avatar_url":"https://avatars.githubusercontent.com/u/471894?v=3","gravatar_id":"","url":"https://api.github.com/users/ethanresnick","html_url":"https://github.com/ethanresnick","followers_url":"https://api.github.com/users/ethanresnick/followers","following_url":"https://api.github.com/users/ethanresnick/following{/other_user}","gists_url":"https://api.github.com/users/ethanresnick/gists{/gist_id}","starred_url":"https://api.github.com/users/ethanresnick/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ethanresnick/subscriptions","organizations_url":"https://api.github.com/users/ethanresnick/orgs","repos_url":"https://api.github.com/users/ethanresnick/repos","events_url":"https://api.github.com/users/ethanresnick/events{/privacy}","received_events_url":"https://api.github.com/users/ethanresnick/received_events","type":"User","site_admin":false},"created_at":"2015-08-11T02:14:05Z","updated_at":"2015-08-11T02:14:05Z","body":"> Is there any externally-logical ordering that is imposed on the resources that the API returns already\r\n\r\nThe API returns them roughly in most-frequently-used order. I.e., the big/important resource types like Events and People come first, while non-important ones (like SchoolAttendance) come at the end. This is designed to make it easier for someone looking at the docs for the first time to get a sense of the API's major capabilities. But it's less ideal for someone who's looking for a particular resource type (e.g. TeamMembership), because it's hard to predict where in the list that type'll be; abc order solves that.\r\n\r\n> I'm not sure what the stance of the JSON API spec is on implicit guaranteed ordering of collections, so it may or may not be appropriate to do it in the API.\r\n\r\nJSON-API supports a `sort` query parameter that can take arbitrary values (i.e. the values can but don't need to correspond directly to resource field names), so any implicit ordering can always be made explicit/reliable for a contract just by adding that parameter. So, perhaps the docs url should be `api.tnyu.org/v2?sort=importance`. Then, we could have a different URI for `api.tnyu.org?sort=name.plural`. \r\n\r\nDefining these URIs on the API side probably makes the most sense long-term, though it would take (much) more logic to implement it there than it does to implement it on the client. Still, maybe it's worth doing. \r\n\r\nThis conversation's actually gotten me thinking though...maybe we don't want to sort the home page in ABC order at all? I.e. if the advantage of ABC is just that it makes it easier to find a particular resource type by name, maybe we can just put a \"Filter\" text box at the top of the page and, as users type into that box, the cards for resource type whose names don't match their input just disappear? So, a user would type \"T\" and then only the \"Teams\" and \"Team Memberships\" cards would be left. This would let us get the benefits of most-important-ordering, namely, that Events and People can still come near the top, while also giving us most of the benefits of ABC ordering. (I say \"most of\" because typing in an input to filter is a bit less discoverable/requires more user effort than just having the cards sorted already.) Thoughts, @grungerabbit?\r\n\r\nIf we go that way, then we don't have to implement anything else on the API side. If we instead just show the cards in abc order upfront, then I think we could support that ordering on the API side (with `?sort`)... but that we should also support it on the client side, because, when we release the intranet as a library, I don't want every API that uses it to need to implement the `?sort` logic themselves—that seems like an implementation burden that we can pretty easily take away from other developers. In that case, I'd refactor this to put the logic in the main controller as @maxdumas suggests and resubmit it to `develop`."}}