Show HN: Atlassian Design for Bootstrap v5
github.com
Atlassian Design for Bootstrap 5. Beautifully crafted Bootstrap components ready for your next project.
github.com
People will nit pick over, sometimes justifiable, UI/UX issues with the product but the level of hatred you see can't be explained by that alone.
In reality the problem is with Scrum and Agile.
Jira has implemented all those features because that's what the industry (managers and people that like control) wanted Agile to become, so, to make money they did so. I don't blame them for that, they aren't the defenders of Agile. Again, the problem isn't Jira.
If you strip away all the reporting, burn down charts etc what you are left with is an exceptionally powerful Kanban board with, in my opinion, a solid user experience.
- Trello feels like a toy (it's not, we use it extensively for core business activities but I don't like it for software) - GitHub issues feels too focussed on devs - Todoist is clearly designed for solo use - Monday.com is for more generic project management - Notion is a mess when you have a lot of tickets - I don't want to use ClickUp
After going though all of those I realised that Jira is pretty good for me.
It's possible to use Jira well (ish) but it requires constant effort. If you ever take your eye off the ball you'll have irreversible transitions and workflows that only certain people can do and you'll start using ticket numbers instead of issue descriptions and end up fighting the tool more than working.
But I guess the mystery to me is, without all the "extra" - how complex is this topic space, really? It feels like it's just a shim over something like Github issues so you can render the board, rather then anything else.
Except the reporting is what the paying users want i.e. the managers.
On top of that, good luck making changes to anything. The structural configuration for board, screens, and fields is buried in a maze. Something as simple as changing the options on a single select custom field (say, to add a new team) consistently took me upwards of 30 mins of clicking fruitlessly through the UX every time I had to do it, because it was so unintuitively buried and hidden.
Personally, that's why I despise Jira.
Not from my perspective, I will happily 'dunk' on it because the UI/UX is so ridiculously slow and non responsive sometimes. It's a nightmare when we need to close a particularly large sprint out. Everything doesn't need to be 'drag & drop' . Trying to navigate the right fields to update is a numbers game, even if its a simple waterfall flow.
They tried to do everything and that's great. But the UI suffers for it, its slow, incredible memory heavy to run on-premise, crashes in the browser frequently. It's not the best tool for the job.
The custom workflows are often mandated by clueless managers, and often even if you have clueful JIRA admin they will silently try to fix manager's dumb idea instead of having the manager eat the turd sandwich.
Once, a coworker of mine decided that enough is enough, and decided to implement a workflow exactly as specified by management.
After week or two of totally lost productivity and reporting, system-supplied workflow was returned to and the manager never again tried to play with workflows.
Developer issues (eg. github issues) aren't the same as helpdesk requests, and aren't the same as customer enquiries. Yet Jira happily smashes them all together.
The freedom Jira offers managers is not for the benefit of any workplace I’ve ever been. I much prefer every single tool I’ve used that isn’t Jira for this reason.
All the issues you mention aren't a problem with JIRA but your workplace (if it's an issue). There are hierarchies and processes and you don't like it. Whether JIRA or manual it'd have been the same.
> You usually have to fill in a bunch of unnecessary mandatory fields before you can do anything
It's configurable. It's not for you but for management. So it's not "unnecessary".
> and by default you have to follow the workflows that have been set up by someone with more permissions than you
and by default you have to do work set up by someone with more authority than you.
And yet, as if by magic, they consistently happen at workplaces that use JIRA, and not at workplaces that don't.
If it were manual, no-one would stop me submitting the form with the field not filled in where it doesn't make any sense. In the unlikely event that someone chose to make an issue of it, I'd be able to at least ask them wtf I was supposed to put in that field.
> It's configurable. It's not for you but for management. So it's not "unnecessary".
They are unnecessary. Management doesn't actually use them and they don't even make sense for a lot of issues, but the tool seems to nudge them towards having a bunch of mandatory fields (maybe added fields are mandatory by default or something?)
> and by default you have to do work set up by someone with more authority than you.
Sure, but most workplaces don't have a magic trapdoor where if you accidentally pushed the wrong elevator button then you can't come back without a manager letting you out. And they certainly don't have a 20 second lag on the elevator buttons.
Considering that there are so many variables at play, it's a very flawed conclusion. You don't have enough data. It's not magic. You're just choosing to see it as you please.
> If it were manual, no-one would stop me submitting the form with the field not filled in where it doesn't make any sense.
It just works both ways. You can't have everything. Yes no 1 stops you submitting the form but you also potentially miss a lot of things. When it's discovered the context is lost or the friction is too high or they don't even know it's missing to begin with.
You might as well just not submit it then.
> They are unnecessary. Management doesn't actually use them and they don't even make sense for a lot of issues
Well then take it out? Giving you a gun doesn't mean you need to kill someone. Responsible adults? If you buy the tool at least there should be some effort in making it work?
> Sure, but most workplaces don't have a magic trapdoor where if you accidentally pushed the wrong elevator button then you can't come back without a manager letting you out.
Again, you speak as though someone died because you had a gun - not because you killed them. Maybe consider that the company should be implementing a process or system and buying a tool to facilitate. They need to then set that tool up. If all they do is buy the tool and sleep that's on them. A lot of larger companies do hire dedicated specialist to configure and maintain workflows and the like.
So I'm not saying JIRA is the best or anything. It's just never designed as something that works out of the box for everyone. A lot of the "enterprise" alternatives are way worse and that's what it won over. I'm sure it can do a lot better but again I don't see it as the problem in most cases. It's like if you buy a Mac and tried to use it as a PC and complained about not being able to swap the GPU then I'm not really sure it's the Mac's fault.
I've been working in software for about 15 years across a wide range of companies and industries. JIRA or not is the best single indicator I've found for whether a workplace will suck (in particular, switching to JIRA is the most reliable indicator of when it's time to leave).
> Well then take it out? Giving you a gun doesn't mean you need to kill someone. Responsible adults? If you buy the tool at least there should be some effort in making it work?
> Again, you speak as though someone died because you had a gun - not because you killed them. Maybe consider that the company should be implementing a process or system and buying a tool to facilitate. They need to then set that tool up. If all they do is buy the tool and sleep that's on them.
I can't take it out, because JIRA only lets managers/admins/what-have-you do that, and they aren't the people who have to fill in the pointless fields and don't care.
A properly designed gun will have safety features (there's simply no excuse for not being able to undo the transition you just did, that's the equivalent of having a hair trigger and no safety), and a responsible gun store will offer safety training to buyers.
Good defaults are important, and other tools in this space manage to get them right.
I don't really like Jira:
* it is on the slower side of things, unless you throw a decent amount of hardware at it in a self-hosted deployment (then again, something like OpenProject is similarly slow, the only truly fast piece of software in the class I've experienced was Kanboard, but it's very specialized and really light on features, so not a 1:1 competitor)
* the API isn't all that pleasant to use, even though you can sort of understand that due to the level of complexity/customization (I recall struggling with a Java client library, when I had to find issues based on the values of custom fields and some other constraints I think, but it was a while ago)
* their text formatting was pretty horrendous and unreliable on the version that I used, which is perhaps my biggest actual gripe: if you had snippets of code under and issue, as well as lists, images and a bunch of other formatting, it *reliably* broke for me whenever I tried making any changes, when I tried pasting stuff in, or using the UI buttons for formatting
Take my "complaints" with a grain of salt: I last used it a while ago and therefore don't remember super specific details, aside from the text formatting being an absolute pain every single time.
Also I thought API is great, or at least the community python package is[0]. It's probably the best experience I had integrating with an issue tracker.
FWIW, I used it in a semiconductor company that used it to manage work on their ASICs, so things were fairly heavily customized and there were over 100k tickets.
And I can only guess you've never had a product manager justifying their jobs by adding in a bajillion custom fields and field values into an issue. And then filters that use those. This case is a user problem, but the Jira does little to prevent or help.
1. Usually integrated with the Enterprise IDP
2. apps/modules usually are part of the security boundary of Atlassian, meaning little compliance headaches if any.
3. Out of the box scaling of per user licenses since individual apps can't have their own independent user limits, they use the whole Atlassian user count. So, if your customer needs just 10 licenses but their Atlassian suite has 500 users, they must purchase at 500 user cal.
4. Atlassian Jira/Confluence are very sticky at the enterprise level. Yes, teams may move to Gitlab, but most customers prefer to stick to Jira/Confluence.
Rephrased, I think an agency or company that follows the AWS model of "borrowing" open source projects and converting them to a paid service would work would do well. Wrap a open source solution around an Atlassian or similar PaaS app/module.
You might find bourbon more useful.
What I want is more-or-less what I started doing on https://gitlab.com/mushroomlabs/zenstyles. I took some of the code from materialize.css and stripped it from anything that depended on javascript and anything that required a specific layout definition. Basically, I wanted something that could work as a "classless CSS" that used the basic building blocks from materialize.css, so that I could use with code that was based on headless-ui components.
This approach let me, e.g, use my hub20 checkout component (vue.js) without any styling on its own and let people integrate whatever "theme" they wanted. I only got to implement 2 "zen styles" following this approach (the other is on https://github.com/mushroomlabs/hub20.frontend.app/tree/mast..., and one day I will get to extract it out and move it to the "zen styles" repo) but it was enough to prove to me that this approach was not only possible but made my work a lot easier.
In my view the question is "why shouldn't they build on top of an existing stable base?".
If I made that decision for a business, we would have started the discussion there. An argument for creating our own framework would need to convince me of its value to the business. Just because the company has resources to do it, doesn't mean it is the best use of those resources l.
I can't imagine any company wanting a distinctive design for their components using it.