Feedback from the enterprise - UI/UX considerations for app development (and Atlassian products)

[#1]

Hey all,

After using the Atlassian products and Marketplace Ecosystem apps for quite a number of years within a large and complicated enterprise - I've noticed that there's a few UI/UX issues that cause considerable pain that may not be quite so obvious/impactful with smaller organizations or data sets, so thought it would be valuable to outline some of the suggestions we've fed back to vendors, as well as having other users contribute to the thread so the information is more readily available - with some business justification as well so it's easier to understand the impact.

Some metrics from our environment for reference:

• We run
  • Data Center- Jira Software, JSD, Confluence, Crowd, Bitbucket
  • Server - Bamboo
  • Cloud - Trello, ~ 100+ cloud Jira/Confluence/Bitbucket environments 
• We've migrated 70+ cloud/server/DC environments to our single large instance
• We have 24*7 usage from ~ 15,000 users in over 150 countries from every corner of the world in ~ 4000 groups
• Our team is 14 people around the world, supporting not just the infrastructure and platform, but working with the businesses to develop and support their business processes, not just throw a "workflow tool" over the wall
• We're a TAM and Premier Support customer
• Jira - 15,000 projects, 1.7M issues, 1350 custom fields, 800 workflows, 650 statuses
• Confluence - 2400 spaces, 1.5M pages
• Bitbucket - 2200 projects with 9200 repos for 1.2TB of code

On to the feedback:

1. Performance
   • I'll just get this one out of the way first - performance is obviously critical for everyone, and with DC Approved Apps (https://www.atlassian.com/licensing/data-center-approved-apps) providing a base line of quality that may cover some key performance metrics, generating and testing against a very large data set would be another huge step if you're not already. We've been asked to provide our data set to test specific issues with in the past, but this is just not possible for security/compliance reasons, let alone logistically.
2. Sort everything!  If there's a dropdown list of usernames, groups, projects etc - order them alphabetically (or allow a variety of user defined ordering). I was trying to find a group (out of our ~ 4000) and the list wasn't in any sane order. If it's a Jira/Bitbucket Project or Confluence Space - allow sorting by key or name. The only way to find the option was enter each letter quickly enough for the browser to select the right option. If IE still behaves in the same way it used to, this doesn't even work as looking for ABC it searches for anything starting with A, then anything starting with B, then anything starting with C - not anything starting with ABC
3. Pagination - top and bottom of each page, not just the bottom. Using the << First | < Prev | 4 | 5 | 6 | 7 | Next > | Last >> approach helps too. 
4. Pagination and filtering as part of the URL - lets users bookmark specific content, share links with others and with functions like Chrome Custom Search Engines 9https://www.techrepublic.com/article/pro-tip-add-custom-search-engines-in-chrome-for-more-efficient-searching/) using keyboard shortcuts to get to content is a big win
5. Ideally support in place filtering - eg: https://select2.org/getting-started/basic-usage - this makes narrowing down the selection much easier. This should support a  case insensitive %like% as well, not a like% - with so many groups, we need a strong group naming convention, so a lot of our groups start with the same first 6 characters. Having to enter this content when you know the last 5 letters are unique is a waste of time
6. If it's a multi-select option, do not rely on the standard multiple HTML - a number of plugins that we use require us to enable on a per-project basis. Scrolling through a list of 15,000 projects to see what ones are selected is near impossible. Something like https://crlcu.github.io/multiselect/examples/search.html is a much nicer option in my opinion. Bundled with search at the top of each active/inactive
7. Lazy load as much as possible - If loading a large list (groups, users, projects etc) becomes a render blocking event, the total page load time can skyrocket. Deferring the loading of these lists to an AJAX request (only triggered on keypress)
8. Don't limit the max results - a number of core Atlassian products and marketplace apps will provide 10-20 results when you're searching (groups, projects etc) and there's no option to show more results. With larger data sets, it's not uncommon to need to search for a team that matches 50, 100, 200 results. If the result you want would be result 51, and you can only see 20 - there is no way to find the result you want. Good ways I've seen of working around this are:
   1. Infinite scroll/pagination - if the user scrolls to the bottom of a list, trigger the next page of results
   2. Support more filtering options - eg: if looking for an Issue, allow the user to select a Project as well 
9. Wider select lists - if a username dropdown list only supports 15 or so characters, we have a large amount of users - in the same company, or over multiple companies - that have the same first.last name - the only way to properly differentiate users is often by their email domain - often this is truncated, or, if the only thing displayed is First Last (displayName) - you have NO idea which version of a username you're adding. This is much more critical when you're adding permissions for a user. You don't want the wrong John Citizen looking at that sensitive HR project you've just setup
   1. If you do need to truncate the dropdown values, ensure that the full content is at least displayed when hovered over
10. API
    1. Build API first and have your UI leverage your REST API - Instead of building UI functionality first, then having users ask for REST support, this approach means REST has feature parity
    2. Be efficient with REST calls - support expand flags etc - Numerous times we've gone to integrate with a product and we need to make a call to a single REST endpoint, iterate through the response, then make further REST calls to get more detail, itterate through those responses, more calls. Allowing a single REST call that lets you drill deeper with expand flags minimizes round trips
    3. Support bulk functions - eg: enabling an addon for a project - support a POST array of projectKeys or similar, not just /rest/plugin/$PROJECTKEY/enable which means you'd need one call for every project you wanted to enable it on 

That's all that comes to mind at the moment, but I know there's more...

As well as hearing from other end users on things they feel could benefit from, it'd be great to hear from the marketplace / product teams on their challenges as well

CCM

[Kat Warner]

Great feedback @Craig Castle-Mead

[Alan Parkinson]

Great list @Craig Castle-Mead , as an App vendor it's really useful.

One of our biggest painpoints is having a large dataset for testing purposes, as you've rightly pointed out customer sets can't be shared so we have to generate synthetic ones

What kind of technical documentation do teams with large environments need to help evaluate an App and set it up for production usage at scale?

[David]

Thanks @Craig Castle-Mead . As an App vendor this is great to have in such a concisely presented list for us to have in mind while developing our add-on.

[Alex Medved _ConfiForms_]

Thanks for sharing this @Craig Castle-Mead 

Will definitely take these as an action points when developing our plugins further.

[Matt Doar]

One of the things I've discussed with Atlassian PMs is that some of the admin pages in Data Center only refer to the current node you are logged into. But since there is no clue about that in the UI, admins assume that the admin info is valid for the whole cluster. For example, try to find out when a User Directory was really last synced.

UI  request: make it clear which pages have information specific to just one node

[Boris Berenberg - Atlas Authority]

@Alan Parkinson for synthetic data, the best we have right now is https://drive.google.com/open?id=0B5jXxv30t8AOZGh5dTktSXh5NHc which is a 2M issue dataset with a ton of other config elements. Proper anonymized data would be great, but not an easily solved problem.