We did the same at one company I worked for. It was a terrible decision.
RxJS is one of those things that is fun to play with until you look down and it's cutting off your legs before you even felt it. Instead of simple AJAX calls when needed in places that are logical, your app turns into this hydra of events flowing everywhere and never knowing why anything is happening or where it's happening. RxJS is what happens when a Jenga tower makes love with a Rube Goldberg machine.
And don't get me started on those damn marbles. We're writing goddamn CRUD webapps!!! We don't need marble diagrams for this. It's like that Mitch Hedberg joke about donut receipts. We don't need to introduce complexity into our simple life.
Some young woman was on stage demanding that all males need to apologize to women in tech. There were other incidents.
Not a community I want to be involved in.
[0] https://docs.google.com/document/d/1g4oh2GGZOsucZfT1YJ5wjDUS...
Secondly, it's great that they're involved and passionate on social justice issues, however I wouldn't lead with that as the landing page gives no idea what the company actually does, offers, or makes.
Thirdly, when you click over to their team, it should identify their role instead of just letting you click to their socials.
^ just my quick first impressions!
And the Award for Metaphor of the week goes to ...
Say I'm installing a toilet, I need to go out and buy one from the hardware store, remove the old toilet, install the new one, and finally test that it works. It's a linear process that could easily be constructed via a series of async/awaits, and I wouldn't use RxJS to model the behavior.
Now, say I'm building a bathroom. You have a shower head, a sink, a toilet, light fixtures, power outlets, tiling, a door, and a window. You have a bunch of contractors. Now you're dealing with N number of sources, N number of tasks that can possibly done in parallel, and N number of possible things you could do in that bathroom depending on how much the bathroom is finished (for instance, if just the plumbing, floor and sink are complete, I can wash my hands)
This was always a hard problem, and not one that is especially appreciated, but I can tell you from experience that attempting to just use promises or async/await is not a scalable pattern.
Good to hear that there’s at least one person involved with it that sees the problem with this. I imagine how the use of whitespace to organize the layout probably looked very simple and attractive in Sketch or Figma at some point. Then reality crept in, and that whitespace was gradually carved up into more and more incoherent pieces. And as that was the only indicator of hierarchy and relationships there was to start with, there’s now no organization left at all. Many screens are just a bunch of words, all imperceptibly different shades of dark gray, strewn out randomly over a solid white background.
To make things worse, they all seem to be implemented in slightly inconsistent ways (you can tell when an h1 is wrapped in ten (10) layers of nested divs, each just containing the next div) so things that should align are all off by a pixel and have slightly different behaviors.
For this particular website I think the design is obstructing the functionality. "Good design is unobtrusive - Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression."
I wonder if people like this stuff? I mean are there people who mindlessly scroll through this crap and like it?
I didn't comprehend how someone thought it would be a good idea to move the button for a new ticket away from the main screen to that sidebar thing where it took an additional click to do so.
Yes lets add another click to the most used function in my workflow...
For one large web app I worked on, we had a setup where browser loading time would always print out in the dev tools console. We had no hard requirement for UI changes to stay under a certain threshold, but seeing that loading time with every refresh during development was enough to keep us mindful of payload.
the issue here isn't the goal itself, it is that such highly visible efforts - "common platform", "common UI", etc. which are very complex technically to do right - invariably bring up to the top and into the deciding positions those "drivers of cross-organizational/functional/etc. change" style people whom you'd really want to be staying far from such important and complex technical issues...
I worked with Jira in 2012-13, it was appallingly slow. Making it even slower is an achievement.
THANK YOU (sorry for shouting). That's my biggest pet peeve with the new UI.
I feel like I'm using some mix of Mac OS X UI and a child's toy. Everything is so big and spread out, there's barely even space for longer text areas.
Don't even think about putting windows side-by-side with JIRA taking half a screen, it's unusable.
Sometimes with Jira updates, I have to ask myself “What WERE they thinking?” It’s good to hear that actually some people (well, at least one!) inside the org ask this too.
Jira is a tractor trailer. It's big, it's powerful, it's a bit slow to get moving, but (1) it can carry just about anything (2) once it gets moving, it tends to stay moving. There's a lot of value in having a "do it all" project management system.
That being said, there's also value in alternatives that are more tailored towards specific needs.
Way faster, way better design and the searchbar was amazing.
In the future, when cursing the developers who are responsible for this, I'll bear in mind that sometimes no matter how good the individuals in the team… it's sometimes impossible to salvage a good product.
That’s scary in a few ways I have a hard time imagining.
as long handle being wholly dependent on a third party whose API access could be pulled anytime .
It's a shame they are killing off the server products to push everyone into the cloud.
Except going to https://bitbucket.org/atlassian/atlaskit/src/master tells you to go to https://bitbucket.org/atlassian/atlaskit-mk-2/src/master/ which then tells you:
> Unfortunately, that code no longer resides here as it’s all been moved to a new closed source location.
The breadcrumb to get to it is a bit crazy, but https://bitbucket.org/atlassian/design-system-mirror/src/mas... is the old mirror, which has a link in the readme to the new mirror: https://bitbucket.org/atlassian/atlassian-frontend-mirror/sr...
Things have been improved with the recent addition of pinned ticket fields, but they still have a long way to go.
Look, Atlassian is a growth-by-acquisition operation, chaos is inevitable
I appreciate your expanation of th Atlassian dev process. I've always wondered how they managed to make JIRA so slow.
If I was in Atlassian's situation this would be the last thing to focus on.
a) This is the biggest ever rewrite of their most important products. In this situation maintaining feature set compatibility is always going to be priority A, B to Z.
b) Their paying customers are mostly in the enterprise space who have very fast internet and stable environments i.e. payloads are quickly cached.
2) They are in the middle of a complete UI rewrite and I've only briefly used it but it's definitely much better than the previous versions. I imagine the Trello acquisition is also going to help them here.
For my other team members, they enjoy Confluence more than Jira, because Jira feels a bit difficult.
The not being able to type fluidly has to be the worst though.
Our team has as well at least brought up the idea of potentially trying other products.
Some of it's probably me not really wanting to get involved with JIRA in the first place (who wants to manage tickets), but in the interest of being a better employee I've been trying to make sure I'm squaring out my work properly for tracking, etc.
And there's certain things, that I'm sure are there, but I just can't find sometimes. Like... how to add an epic easily. There's at least three different views for each ticket (when you create it, when you click it open into the modal, and the full screen view), and things are apparently in different places on those different views?
I'll take some of the blame, but it's a mess.
c) Pushing folks to their cloud offering, partly by
d) doubling the cost of on-prem.
The surprise price bump really pissed off people here; that, combined with doubts about their long-term commitment to on-prem put evaluating alternatives on the list for next year.
Being a tool no one loves is a bad place to start changing a bunch of stuff at once.
The components were mostly handed down to us from a company-wide UI team whose main design goals were to bring commonality across all Atlassian products. This is a worthwhile goal, no one thinks that it makes sense that Atlassian has different editors and even markup languages between (and even within) products. But the result was dog-slow overweight components like the Atlassian editor which tried to be everything to everyone. So when you need to bring in a monolithic highly-customisable 12mb+ component for every text edit field then things spiral out of control quickly. One cool thing, though, is that these components are open source[0]. And it looks like some performance/payload work has been done since I left, thank god.
In my new job I use Jira Server which hasn't been infected with the updated UI, and it's a shame because other than that terrible UI there have been big meaningful updates in Jira. But I'm dreading our inevitable migration to Cloud.
[0] https://bitbucket.org/atlassian/atlaskit/src/master/