Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-46644

new gitHub Organisation icons remove important context

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      The Icons for GITHub organisation folders and multi-branch projects have changed and have removed context that is important.

       

      The old icons where a folder overlayed with an icon.

       

      However the new icons are the icon from github for the organisation, and the icon for the created MutliBranchProject is a random black square that means nothing to me)

       

      These icons remove the concept that "this is a collection of things" and as such they look like a normal job with a custom icon and as such do not stand out when you are looking for something.

       

      The old icons that used overlays on a folder should be re-instanted to restore the cogative link.

       

      //cc James Dumay as Stephen Connolly says this was a UX descision (WAT??!!)

        Attachments

          Activity

          Show
          stephenconnolly Stephen Connolly added a comment - James Nord the icons have not changed, these icons were in https://github.com/jenkinsci/github-organization-folder-plugin/blob/github-organization-folder-1.0/src/main/webapp/images/repo/32x32.png
          Hide
          stephenconnolly Stephen Connolly added a comment -

          There may have been bugs causing them to not be applied consistently, but the original intent from the 1.0 release of org-folders was to use those icons.

          The refactoring to SCM API 2.x moved the responsibility for the icons to https://github.com/jenkinsci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/metadata/AvatarMetadataAction.java and the default folder icon for branch-api is https://github.com/jenkinsci/branch-api-plugin/blob/40370fdd50e9aa8601317a5549ce941d3c2912ee/src/main/java/jenkins/branch/MetadataActionFolderIcon.java which uses that avatar metadata in order to synchronize the icon displayed with the avatar used in the backing SCM... and for GitHub Repositories, they have the "book" avatar and branches have the "branch" avatar...

          In the case of organizations on GitHub, there is an actual avatar URL that can be set and the API gives a clear indication as to whether the avatar has been set.

          Note, for Bitbucket and Gitea, the avatar URL may be an invalid / external / incorrectly sized URL, so the 2.2.x releases will cache and resize the image... and a consistent but random "space alien" will be presented in the event that the URL cannot be retrieved or the image resized.

          Show
          stephenconnolly Stephen Connolly added a comment - There may have been bugs causing them to not be applied consistently, but the original intent from the 1.0 release of org-folders was to use those icons. The refactoring to SCM API 2.x moved the responsibility for the icons to https://github.com/jenkinsci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/metadata/AvatarMetadataAction.java and the default folder icon for branch-api is https://github.com/jenkinsci/branch-api-plugin/blob/40370fdd50e9aa8601317a5549ce941d3c2912ee/src/main/java/jenkins/branch/MetadataActionFolderIcon.java which uses that avatar metadata in order to synchronize the icon displayed with the avatar used in the backing SCM... and for GitHub Repositories, they have the "book" avatar and branches have the "branch" avatar... In the case of organizations on GitHub, there is an actual avatar URL that can be set and the API gives a clear indication as to whether the avatar has been set. Note, for Bitbucket and Gitea, the avatar URL may be an invalid / external / incorrectly sized URL, so the 2.2.x releases will cache and resize the image... and a consistent but random "space alien" will be presented in the event that the URL cannot be retrieved or the image resized.
          Hide
          stephenconnolly Stephen Connolly added a comment -

          James Nord I am inclined to say "won't fix" to the issue you describe.

          My preference is that we add a OrganizationFolderProperty sub-type of FolderProperty to branch-api and those properties would have the opportunity to decorate all the MultibranchProject instances in the org folder.

          I can see real requirements where such a property could be useful, but to your concern this would allow an extension plugin to customize the FolderIcon for all the MultibranchProject instances in an org folder.

          WDYT James Dumay

          Show
          stephenconnolly Stephen Connolly added a comment - James Nord I am inclined to say "won't fix" to the issue you describe. My preference is that we add a OrganizationFolderProperty sub-type of FolderProperty to branch-api and those properties would have the opportunity to decorate all the MultibranchProject instances in the org folder. I can see real requirements where such a property could be useful, but to your concern this would allow an extension plugin to customize the FolderIcon for all the MultibranchProject instances in an org folder. WDYT James Dumay
          Hide
          stephenconnolly Stephen Connolly added a comment -

          //cc James Dumay as Stephen Connolly says this was a UX descision (WAT??!!)

          Well my understanding is that it was a UX decision made by James for GitHub Org Folders 1.0... but that would have been like 2 years ago, so whether the same decision would be remade is another story

          Show
          stephenconnolly Stephen Connolly added a comment - //cc James Dumay as Stephen Connolly says this was a UX descision (WAT??!!) Well my understanding is that it was a UX decision made by James for GitHub Org Folders 1.0... but that would have been like 2 years ago, so whether the same decision would be remade is another story
          Hide
          jamesdumay James Dumay added a comment -

          TBH I don't remember making that decision.

          Show
          jamesdumay James Dumay added a comment - TBH I don't remember making that decision.
          Hide
          stephenconnolly Stephen Connolly added a comment -

          James Nord / James Dumay given that we now have the avatar cache, how about we overlay an icon.

          I see two choices for the overlay icon:

          1. Overlay a mini-folder icon
          2. Overlay the provider icon, e.g. github's octo-cat, gitea's teacup, bitbucket's bucket, etc

          Now I think the folder icon is the best option if we want to go that route. In fact with the folder icon we could probably just scale the avatar down 4 pixels for the 24x24 and put the avatar on the folder:

          The scaling gets quite extreme at that point though, we are basically squashing the avatar down to 12x12 to fit on the current folder icon. A better approach would be a new folder icon that has a larger placeholder... or just put a little folder in the bottom corner as an overlay

          Show
          stephenconnolly Stephen Connolly added a comment - James Nord / James Dumay given that we now have the avatar cache, how about we overlay an icon. I see two choices for the overlay icon: Overlay a mini-folder icon Overlay the provider icon, e.g. github's octo-cat, gitea's teacup, bitbucket's bucket, etc Now I think the folder icon is the best option if we want to go that route. In fact with the folder icon we could probably just scale the avatar down 4 pixels for the 24x24 and put the avatar on the folder: The scaling gets quite extreme at that point though, we are basically squashing the avatar down to 12x12 to fit on the current folder icon. A better approach would be a new folder icon that has a larger placeholder... or just put a little folder in the bottom corner as an overlay

            People

            • Assignee:
              Unassigned
              Reporter:
              teilo James Nord
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: