I've used both, and I can only imagine your complaints about JIRA's UI are due to how it's been configured for your use.
The out of the box user experience is the best I've seen for a web application. A robust yet easy to use 'search' feature is at the heart of many things, like the scrum and kanban boards, as well as widgets that can be put on your own personalize dashboard. You get a nice visual designer for setting up workflows, and you can easily create new fields for issue types and have workflow depend on those fields.
I also find Stash to be well thought out and easy to use if your use-case is a pull-request workflow tied to JIRA. Sometimes it's not intuitive how to navigate around if you're just trying to view source, but that's not the selling point. If you're trying to navigate source history, use your local source control client, that's what it's built for.
> I've used both, and I can only imagine your complaints about JIRA's UI are due to how it's been configured for your use.
Exactly. There are some companies that go so overboard with Jira customizations that a single "create new issue" requires hitting page down three times to get to the end. And they arrive at that by adding a field here for the QA team, a field there for the Sales team...
In the end, you get a monster. New users will be exposed to that monster, not the vanilla Jira installation.
Right and now think about who is going to control the JIRA install: the manager or VP or CTO.
Fogbugz's interface prevents this kind of crazy customization and thus it acts as a defense against the craziness. For a custom workflow with Fogbugz you have to grab a plugin. To get my manager to install a plugin for JIRA took weeks (and I still never got access to the REST API or approval for one plugin months later). So Fogbugz is developer-friendly because it makes it harder for a manager to go in an lock things down and mess around. With JIRA, the micromanager seems to be bundled with JIRA... ;-)
Managers find a way. They will just use (or invent) another tool that lets them do it how they want. Now you have two tools, and some poor schmuck (or the developers) will get stuck with the job of keeping them in sync.
Pivotal isn't really a bug tracker though, is it? It's more for tracking project tasks. On some projects, these might be similar things, but when you have a large QA team and customer support teams, I don't think it's going to cut it.
It just depends on the process you put around it. Our team wasn't huge - ~13 if you include QA - but effective use of labels and "task" state management made it great.
I can never remember how to write code into comments or titles. It literally changes from product to product and yet all of the products orchestrate together so that if you do happen to use Stash, JIRA, Wiki, etc all together, then you encounter as many different markup languages as there are Atlassian products.
It really is hellish.
I hope there's some good reason why they can't provide one "comment markup" language to all applications.
So far as I can tell, they did have one common markup syntax for all applications... but then Confluence users wanted a WYSIWYG mode, so Confluence now uses an XML-based format internally, and Stash is a Git tool and 90% of the Git ecosystem loves Markdown, so Stash had to use it too...
Markdown embraces HTML, and so a WYSIWYG mode based around HTML is compatible with Markdown.
Markdown's weaknesses for table design, image insertion, and complex layouts is all handled by HTML and WYSIWYG tools that edit that directly.
That would have solved the Git scenario, and the Confluence scenario, whilst having a single highly predictable markup across all of their platforms.
The problem really stems not from these problems being addressed per product as if they existed independently of all other products. But that's a terrible approach, as few people buy just Confluence without JIRA or Stash, people buy Atlassian because a consistent suite should work better than many myriad tools that don't quite know how to interop. Atlassian's strength is the consistent and integrated approach, so the UX should be focused on strengthening that.
I actually misread the URL as https://xkcd.com/927/ (having memorized that number like everyone else here, I'm sure) until I saw your comment. #277 is definitely not right.
#277 sure seems to me like a reasonable reply to "Whoever designed <such and such> deserves a special place in hell", which is what it was posted in response to.
Atlassian products tend to make me SO mad in this way. Confluence, can I just use markdown? No! Forget that I used it in so many other places. Oh but wait, someone may have built an importer... try to get that installed.
Confluence used to use markdown and wysiwyg, and about 5 years ago abandoned markdown to reduce development costs. They have a lot of non-developer users using Confluence, who aren't good with things like markdown. Our shop didn't like it, of course, since we were all capable of markdown and wysiwyg is never actually wysiwyg.
I could be wrong, but I think it used textile (I believe Confluence predates markdown). I'm not sure it matters a whole lot, but if you wanted markdown it's likely you would have felt underwhelmed with textile.
I fully agree that it's well past the time to switch to Markdown. That and the dropdown things are my main annoyances with JIRA.
It does make sense when you think about the context though - JIRA pre-dates Markdown by two years (according to Wikipedia) and Markdown has only got really popular in the last five years. Back when Jira's text formatting came in, everybody was doing their own thing...
The out of the box user experience is the best I've seen for a web application. A robust yet easy to use 'search' feature is at the heart of many things, like the scrum and kanban boards, as well as widgets that can be put on your own personalize dashboard. You get a nice visual designer for setting up workflows, and you can easily create new fields for issue types and have workflow depend on those fields.
I also find Stash to be well thought out and easy to use if your use-case is a pull-request workflow tied to JIRA. Sometimes it's not intuitive how to navigate around if you're just trying to view source, but that's not the selling point. If you're trying to navigate source history, use your local source control client, that's what it's built for.