Community request: can we have a no-bullshit update on the future AtlasKit?

[remie]

Dear Atlassian design team,

Can you please give us an update on what the hell is going on with ADG and AtlasKit? It all started so ambitious and many of us have been actively integrating AtlasKit into our products hoping for a better future. But lately it seems there have been a shift in regard to how AtlasKit is presented to the community: packages have been marked internal-only, or have even disappeared from the public repository, community contributions (like creating issues) is no longer possible, packages are not updated frequently (effectively blocking us to upgrade to newer versions of React and as such making it impossible to adhere to Atlassian security guidelines), the OSS contract is broken, etc, etc, etc.

In the spirit of the open company, no bullshit values of Atlassian, could you give the community a bit of a heads up on what the future of AtlasKit / ADG entails?

Cheers,

Remie

[remie]

Oh wow… 32 likes. That’s a first. And it’s not even a rant. I think I may have hit a nerve with this one. I’ve already been contacted by an Atlassian to follow up on this, but maybe you can also poke around @nmansilla?

[aragot]

Sorry for asking an additional question but is AUI updated more often and is it more open-source than AtlasKit? I’m starting a project, I was not aware that Atlassian was abandoning AtlasKit, I’d rather start on the right stack.

[JariSanders1]

From a designer point of view, asking developers to use your strict design guidelines and implement packages into their applications, but not fixing bugs or updating design resources for over 2 years is not really no-bullshit.

Personally I’ve made the decision to create my own Atlaskit design library in my spare time as it takes more time to use the tools Atlassian provides than when I use the outdated resources they provide.

Picking a single design tool with less than 50% market share (Sketch) is not a disaster, but at least make sure that you serve that single group well. If you can’t, ask your community for help the same way you allow developers to improve your software via the Marketplace, or hire the amazing Buzz Usborne who helped you build Atlaskit for another couple years to finish the rest. If he’s unavailable, don’t hesitate to contact me, happy to help out.

My main pointers for turning Atlaskit into something no-bullshit:

• Up-to-date overview of which elements are in use, which will be deprecated.
• Make resources accessible. It’s not 2000 no more, there is more than a single design tool.
• Share your roadmap. Inform developers and designers of upcoming changes prior to changes happening. Even the most secret companies do this better than Atlassian right now.
• Consistency. In every way possible, including but not limited to: design resources, documentation, roadmaps, across each service/product, etc.
• Take this serious. Seriously.

Lot’s of things that can be improved, but it has to be said that some of the things Atlassian is building internally are very impressive. About 2 years ago Atlassian presented a great custom Sketch plugin and built-in accessibility tools, amazing if you ask me, but worthless if not in the hands of your community. Would like to make clear that I understand 100% that this is not the fault of the amazing developers and designers working on Atlaskit / ADG every day, major kudos to you, change is needed higher up.

[JariSanders1]

@jsyip Hi Jennie, I saw your reply earlier on this topic. Maybe you can tell us more about the plans to make Atlaskit a more reliable entity that will allow more people to build amazing applications for the Marketplace and turn Atlassian products into even better products.

I can’t imagine a company like Atlassian building a style guide, slinging it online and simply leave it there for over a year without any changes in the changelog and no updates to their resources since 2018, would be great if you could inform the community!

Thank you!

[Maarten]

As a designer I recognize everything Jari has said. The release of the ADG Sketch Library was very promising, but unfortunately it was outdated since the start. There’s no consistency between the Sketch Library, ADG, Atlaskit. And AUI is also still out there, with it’s own incomplete guidelines.

The first thing you see on the Atlaskit website is this great promise:

Atlassian’s official UI library, built according to the Atlassian Design Guidelines.

Unfortunately this is not true. It’s very frustrating to work with design documentation that does not match the ui library. For me as a designer, but also for the developers I work with.

I have also made the decision to build my own ADG library in figma. This took away one of the sources of information. But I’m still moving between ADG, AUI and Atlaskit to find what I’m looking for.

The most important thing is that your design guidelines and ui library are up-to-date. Support of one or more design tools are a nice bonus, but in the current state it only adds to the confusion and frustration.

[sven.schatter]

Congratulations to @remie for getting the first ever great topic on CDAC! There really seems to be high interest in this topic!

[remie]

I only imagined ever getting this much likes for announcing my departure from the ecosystem (predominantly from Atlassian Staff).

Anyway, having earned this questionable honour makes me feel entitled to summon random Atlassians in this forum. So here we go:

@rwhitbeck @akassab @epehrson @jlau2 @viqueen @kkercz @WarrenChen @jsyip @tpettersen @mpaisley

[rwhitbeck]

Hey folks, I know there was an internal discussion about this thread a couple of days ago. I went and checked and found that the AtlasKit team is working on a reply to this thread. A reply is coming, thanks for your understanding.

[sven.schatter]

Thanks @rwhitbeck! I personally really appreciate comments like these, letting us know that an answer is coming!

[DanielDelCore]

Hey @remie,

Thanks a lot for reaching out and apologies for any inconveniences caused on our part. We want to acknowledge that recent changes have complicated things for third-party developers so your feedback is definitely warranted and welcome!

It’s still important to us that third-party developers can be productive with Atlaskit. The team is actively looking for opportunities to improve in that regard whilst also balancing our internal requirements. It’s worth sharing the motivation behind why that decision was made. This is summarised in the README.md of the atlaskit-mk-2 repository:

In an effort to improve how we manage frontend code across Atlassian, we needed to first co-locate all our front end code in the same place. As a result, we decided to close the Atlaskit repo for a short period of time before re-opening it. You can still view the source

To shed some light on what’s going on behind the scenes, these changes are still rolling out internally. Tooling, logistics and security measures are being put in place to ensure the transition happens in a secure and non-disruptive way. One sacrifice we had to make however was the introduction of the public (one-way) mirror, intended to act as a “window” into our codebase for reference purposes. External contributions have been paused as a result.

That being said, we really want to stress that Atlassian are continuing to invest in the Design System, and we are still building new features and improvements as well as fixing issues. We plan to share that exciting work with our ecosystem and vendor partners in the future, just as we have in the past.

To elaborate on some of the specific points you raised:

packages are not updated frequently

While our public mirror is only updated on a weekly basis , our packages are still updated and published to NPM as per usual.

I’m curious though, would increasing the update cadence of the public mirror help you find the source of bugs and various behaviours? Are our docs missing important pieces of information that lead you to look through the source code?

packages have been marked internal-only, or have even disappeared from the public repository

Atlaskit has grown over time to include the source code of many Atlassian teams, admittedly the terminology for Atlaskit, Design System and ADG has become somewhat blurry. The distinction I would like to make here is that the Design System and ADG are intended for internal and external use, while other packages which previously were public and have seemingly disappeared were designed for internal use only. We’ve had to make the difficult decision to formalise this distinction and as a result feel we have potentially made some holes in our feature coverage more apparent. My question is what functionality are you now missing? Could you please share the packages that have disappeared which you still need access to?

community contributions (like creating issues) is no longer possible

It is definitely still possible to create issues and ask questions via our Jira Service Desk. Please let me know if you’re unable to access this.

While we love the idea of contributions, we’ve intentionally prioritised efforts that are more worthwhile first ahead of a revamped contribution process, based on the fact that we’ve had so few contributions in the past. There is a desire to enable this again, but currently the one-way mirror is the compromise we’ve made for the foreseeable future. I’ll be sure that any changes in this space are promptly communicated with the community.

We really appreciate your patience and understand your frustration while we work through these challenges. In the meantime we’ll be sure to keep our channels of communication open with the community, don’t hesitate to reach out! The best place for that is always our Jira Service Desk.

Cheers,

Daniel Del Core,
Design System Developer

[danielwester]

@DanielDelCore

It is definitely still possible to create issues and ask questions via our Jira Service Desk . Please let me know if you’re unable to access this.

For anything vendor facing when it comes to things with bug reports - can we please stop with the service desks?!? It stops other vendors from seeing what’s going on and is just frustrating.

I guess another way of me voicing my frustration with the JSD usage - why are you using it? It really stops collaboration between Atlassian and the development community…

[BobBergman]

It doesn’t help that different Atlassian teams handle their service desks differently. The developer community has recently been trained that using some prominent service desks like DEVHELP is a waste of time. How are we supposed to know which services desks are black holes and which ones are useful?

[Grzegorz.Tanczyk]

@DanielDelCore Would it be possible to make a public mirror of jira-frontend repository? Just like GitLab is doing with their product(entirely open source), Redash, or even Discourse(the platform powering this forum). In case of Jira/Confluence it would mean that we as plugin vendors can learn how to use AK, and create best possible experience for Atlassian user base.
Very often I find docs/examples of AK as insufficient, lacking of context, detached from the actual user experience, or peculiarities of available REST endpoints. Then I need to align UX of our plugin with the host product, which means a lot of reverse engineering. Eventually I learn how much AK is hacked/forked internally by Atlassian.
Adding more to the injury: Most of Marketplace apps are closed-source, which means there are no publicly available real examples of AtlasKit usage.
Please consider doing an experiment at Atlassian: frontend development with just AK docs, without access to Jira/Confluence repository, neither snapshot, history of changes, internal confluence, or search over slack discussions.

I perfectly understand that it doesn’t make sense to OS something that is not useful outside of Atlassian internal network, but OTOH being tightly coupled with internal infrastructure can be considered as a code smell, which may lead to another set of problems in future.

The only alternative is Atlassian on-permise products source code, but unfortunately their adoption of React/AK is marginal, and will never reach the scale of cloud. This source code is also not easily accessible for everyone.

While we love the idea of contributions, we’ve intentionally prioritised efforts that are more worthwhile first ahead of a revamped contribution process, based on the fact that we’ve had so few contributions in the past.

Perhaps one of the reasons for this is that Atlassian forbidden to use design system assets outside of Atlassian context, which inhibited adoption of AtlasKit outside of Jira/Confluence ecosystem.
Another reason might be that it’s not hosted on GitHub, unlike for example react-beautiful-dnd, which turned out to be a great success.

My 2 cents, post-mortem thoughts, but I hope that it helps.

[wseliga]

I wholeheartedly second what Daniel Wester wrote here.

Communities are not built with service desks or closed ticketing systems. Communities are built by open forums, open discussions, open source, open bug reports, etc.
Open is the key thing. AFAIK Atlassian embraces “open” as the key world. It would be great to see it re-applied to Atlassian ecosystem.

I really strongly believe that this “openness” was the key component of Atlassian success in creating such a vibrant ecosystem and marketplace. First apps (plugins) were created mostly because the source code of Jira and Confluence was effectively open, issue tracker was fully open (jira.atlassian.com), forum was open (forum.atlassian.com on Jives), docs in Confluence with first plugins was open for every contributor, a few early valuable plug-ins had fully open source code (e.g. Jira reports & gadgets, SVN plugin) and other people could easily learn from it how to solve various problems (as yours truly in 2006).
Service desks where not what created this ecosystem and made it successful. I’d say - they are killing this ecosystem. Closed service desks make access to information very difficult, they isolate vendors, fragment ecosystem and create environment which promotes those who have access to information over those who provide the best value to customers/users.

I really cannot see why the community should use closed service desks for anything different than direct vendor <-> Atlassian affairs (e.g. handling payment issues, refunds, sponsorship logistics etc.) and reporting security problems.

Cheers,
Wojtek

[DanielDelCore]

Thanks a lot for your follow-up questions & responses so far! Some really good points have been raised. I’ll try to address them as best I can

Up-to-date overview of which elements are in use, which will be deprecated.

We actually have a deprecations page on the Atlaskit website with all packages we no-longer support. It is also automated so changes in the future will be accessible there.

Share your roadmap. Inform developers and designers of upcoming changes prior to > changes happening.

Our team would love to do that, we’re looking into a few possible avenues to improve this at the moment.

Consistency. In every way possible, including but not limited to: design resources, documentation, roadmaps, across each service/product, etc.

Please help us by letting us know about specific discrepancies and we’ll try our best to address them

Very often I find docs/examples of AK as insufficient, lacking of context, detached from the actual user experience, or peculiarities of available REST endpoints.

To be totally transparent here, we’ve received this feedback internally as well. You’re right our examples don’t have enough context on how or when a component can be used or composed with other components. We’re working on improving our documentation in this regard.

[DanielDelCore]

Hi @wseliga & @danielwester,

Thanks for the feedback!

Regarding our usage of JSD, I just want to clarify a few points you’ve raised, separate to the other comments .

why are you using it?

Our Jira Service Desk is used for both internal and external issue tracking. Since we manage a lot of different services and have users from both engineering and design backgrounds, we lean heavily on the ability to narrow down requests into specific categories and pass the information on to the relevant team members.

Communities are not built with service desks or closed ticketing systems

Our JSD and backlog is actually open to the public, you should be able to see, track and collaborate on open tickets here (let me know if not).

It really stops collaboration between Atlassian and the development community

Would you be able to share some details on this point? Is it due to a lack of visibility or something else? Do you think any tools or products could help alleviate this problem?

Cheers!

[JariSanders1]

@DanielDelCore Thanks for replying to some of the questions.

Please help us by letting us know about specific discrepancies and we’ll try our best to address them

I understand this from your point of view “without a ticket there’s no issue”, I get it. But this is not an open source project we’re working on together. Atlassian is demanding us to use their standards, packages, comply with their guidelines, etc. all while vendors are bringing in millions of dollars in extra revenue through the Atlassian fee on sales through the Marketplace. I get the fact Atlassian takes a cut from our revenue, but I expect not to have to invest days, if not weeks or months of my time to be able to comply with your guidelines, does that make sense?

With all due respect, I’m not going to invest even more time to solve your internal issues. If you want that XX% cut, make sure it’s clear to vendors that those dollars are invested back into the ecosystem rather than shareholders. Multiple Atlassian teams are now telling us to ‘file tickets’ and ‘let you know about discrepancies’ across dozens of projects, products and teams while vendors are just sat here like lemons - trying to fix Atlassians problems. Not very much a no-bullshit situation.

We’re working on improving our documentation in this regard.

Like mentioned prior, there are 2+ year old issues we’re dealing with here. It’s great you’re working on things, but during those 2 years we’ve been dealing with making money, resulting in Atlassian benefiting $200 million Marketplace revenue in 2018 alone. I hope Atlassian understands that that’s simply insane.

Solution time
Although still not 100% fair and the way things ‘should’ work but maybe if Atlassian would start with some kind of bug bounty program for ADG/Atlaskit/Forge-ui both visual, technical and for documentation your vendors could help fix your issues while generating some kind of return on that investment.

[danielwester]

@DanielDelCore

Would you be able to share some details on this point? Is it due to a lack of visibility or something else? Do you think any tools or products could help alleviate this problem?

Using a regular Jira Software project would be a lot better. Basic example:
External developer 1 finds an issue/bug or have a basic problem. They report it through JSD. Atlassian at some point triages and fixes it - everyone happy… That’s the happy path.

But if External developer 2 somewhere else finds the same problem. External developer 2 files a ticket through the same JSD instance and then starts talking to other vendors and developers. At some point External developer 1 and 2 will sync up and realize that they have the same problem. There will be grumbling etc. If they come up with a workaround - there’s a good possibility that it won’t be reported back to the JSD instance since it’s a closed system. Which means that when External Developer 3,4,5 etc come along - the don’t gain from what 1&2 discovered.

You could encourage to use the community site - but that’s not really what a discussion forum is. Thus - can we use a real Jira software project where there can be public commenting (and links shares). It opens up the communications and reduces the frustration.

@DanielDelCore after looking at the backlog - I see that I can see the issues. Y’all are the only ones using a JSD project without using JSD stuff in Atlassian. But not knowing that I can see the backlog - I would expect it to be the same as the other JSD instances (vendor specific, walled content). So I’ll back off a little bit about using JSD since you’re really using JSD it seems? But usability of it of shareable links though…

[remie]

@DanielDelCore thanks for your reply (and for engaging further into the discussions).

First, I want to really really stress that the frustration that you might hear in all the comments on this thread (and I think I speak on behalf of most of the ecosystem vendors) is not directly aimed at you personally or the Design System team. As the team member responding, you will get the mentions and all of the heat, but please don’t take it personal.

Given that we do not have a clear overview of the Atlassian org chart, it is sometimes difficult to address the right person with our issues. I think that some of the frustration towards AtlasKit / ADG should be directed to higher-level management and not the Design System team.

Having said that, I would also really want to keep this discussion a high-level topic about collaboration. So I don’t think it is productive to go into specifics details of what components we are missing, or whether or not the public repo is good enough. Those are implementation details which we can iron out at a later stage.

The core problem I was trying to address is that the Ecosystem is not treated as a proper stakeholder, even though we are expected to use ADG / AtlasKit when building apps.

From the perspective of stakeholder management, your answer is dodging the most important aspects of my open company, no bullshit request: a clear communication on what is happening, why it is happening and what you are doing to mitigate the fallout for your stakeholders.

To give you some reference, imagine that you are telling your manager that you will be starting a cleanup/migration project which will consume all available resources from the team, without a clear scope (because uncertain) and without any possible estimate on timing. That’s the state AtlasKit / ADG is in right now for vendors. I don’t think your manager would buy into it, and neither does the Atlassian Ecosystem.

We need the Design System team or it’s management to be transparent about what is happening, what we can expect and when we can either expect it to finish or get the next update. Preferably without us having to ask for it again and again.