Peculiar UI design choices

[ASDFGerte]

I'm still moderately new (less than a week with jira), but have spend a substantial amount of my past days with learning. My current setup is company-managed, scrum.

I can look over some menus not being the easiest to navigate, or some details with selection/deselection, and even the occasional "whoops something went wrong"-crash (I stopped counting - they either don't persist, or I can immediately tell what caused it). However, for some oddities with the main focus of attention, the board, I wonder, if I didn't just miss something? The following are my observations:

 - The only way to add an icon to a card is by abusing the site-global and unique "priority" field. There, you can specify generic URLs for the icon images, and it will neatly show on your card. However, you can't have a second, and need a transparent pixel for when it shouldn't be there (which still displays a tooltip, but oh well, that adds "priority" for whatever reason anyways, therefore is already weird).

 - Three extra fields can be displayed, but only as plain text, without any style, format, or graphic. Each one always needs an extra line, displaying a ridiculously ugly "none", in case there is no information, bloating the card.

 - Swimlanes for stories hides all extra information from the story itself

 - While normal labels don't have color (where it might be useful), epic labels must have (background-)color, are very centered on cards, and therefore stand out more than issue titles themselves. I had to deactivate them for this reason (the option at least existed, although being imho hidden in the weird location, instead of "card layout", where i would have expected it).

Is this how it is right now? Is jira cloud just still very new, and things frequently change? With less than a week to go by, i can't tell.

PS: I know i can show one color on a card, based on a JQL. That's a helpful indicator, which can be used for anything, and is very welcome.

[Jack Brickey · Accepted solution]

Hi @ASDFGerte , this seems more like a discussion than a question. For the most part I thing your observations are accurate. I think maybe your expectations simply are not being met. Regarding displaying an icon on a card I'm not exactly sure what your goal is there but indeed cheer is not designed to do that. As far as I recall the server version behaves similarly. Now maybe there's some ad on that would afford such an option but I'm just not aware of it. BTW, Jira Cloud is not new at all.

[Nic Brough -Adaptavist-]

Cloud is significantly over a decade old (it got rebranded from "on-demand" to "Cloud" around 8 years ago, and had been going for years before that), and boards and cards were implemented on Server well before Cloud existed.

Given over 15 years of card evolution, maybe there's a good reason you don't get to put a lot of icons on a card?

[ASDFGerte]

Maybe i am just expecting potential additional information in places, where it isn't necessary, because of not having long enough experience with normal usage of jira. I've primarily done test projects so far, trying out features, seeings how things interact, and going to the limits of what's possible. Looking at alternatives, jira still seems to be a step ahead of competition.

I am only a bit confused, because in my mind, allowing a few more icons would be very little extra work ("priority" already does it, so the code is half done, and there is readily available free space for a few). This makes me wonder, whether it was a deliberate decision, to not allow any, and why (abusing "priority" seems unintentional, although working well). It would give people extra liberty, in how to convey some information visually, with a small footprint (not even an extra line), directly on the card.

An example for what i am still considering how to solve: When having a bunch of utility packages, which are each too small to be their own project, i thought about using components, to distinguish them. Sadly, displaying what component an issue is for, on the board, can only be done with uncolored text, in an extra line.

Generally, it's about increasing the speed, in which a developer can see, what an issue is about. The more cases, where the detail view doesn't need to be opened, the better.

I'll probably get a better understanding in the coming weeks, as i'm giving jira a shot regardless.

[Nic Brough -Adaptavist-]

This stood out to me:

"Generally, it's about increasing the speed, in which a developer can see, what an issue is about. "

Imagine two simple cards:

1:  I want another cat in my house before my birthday.  27/6/2022.  Ideally young, so that I don't have to say goodbye to them for a few years.

2: 🐱 

Which one of these two stories actually tells the story?

[Jack Brickey]

How about ....

Young 🐱 4 🎂 (27/6/2022)

in all seriousness Trello is better suited for visual images but it doesn't have the agile features. I would not disagree that some teams could benefit from more graphical capabilities on scrum/Kanban boards. However for me it is not an important feature and, other than playing, I would likely rarely use and likely tire of it quickly. I tend to focus on low maintenance boards for issues that move quickly.

[ASDFGerte]

Thanks, my guess is more and more, that what i am concerned about is not as relevant in real usage, as i envision it to be.

I'd have rather thought about some sane shortening of cards, not from a two line sentence to a single emoji. Let's take what already exists, priority has a graphic "⛔" available for "Blocked" (not assigned by default, but the svg is there), which would display inline with the issuetype, and story-points (not enlarging the card at all, yet adding a distinct visual key for the problem). The current alternative is adding a whole new line with the black on white text "Blocked". I just feel the icon would be considerably superior. Similar things happen, when one e.g. needs swimlanes for something other than projects, yet wants to identify them. In that case, a small icon for the project would be useful. These are only a few examples, but it's a general concept - there is a reason for having small visual cues in interfaces.