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.
It definitely is not working the way it’s supposed. As an example of the tragic of the situation I can provide this Atlassian Support
Since I didn’t find any clear way to report directly to atlaskit, I used generic approach, after couple answers I was referred to community forum, while it’s clear bug in source code, where typescript 3.8 is more strict with imports then older versions of typescript.
I have to admit we slowly start on replacing couple of easier atlaskit components with our own component library and as I get from this thread we maybe should invest even more resources into it.
As if usage of outdated styled-compontents library version was not reason enough…
By moving to a one-way mirror for Atlaskit, Atlassian is making it hard for other people to work with the code. If I wanted to use a specific Atlaskit component version in a product, I used to be able to pull from the atlaskit-mk-ii repo, check out the “my-component@1.2.3 tag”, and find exactly the code I needed. I can also easily diff historical versions of a component to see why (say) upgrading from 1.2.1 to 1.2.3 broke my app.
By moving to this one-way weekly sync, all of the tags are gone, so I can really only see whatever is the tip-of-tree and there is no way to find a specific version of a component. And is this tip-of-tree code representing code that is released, work-in-progress, or something else? There’s no way to tell without checking the individual package.json. The commits are also applied without any history, so you also can’t even easily see changes between the bigger mirror syncs (“git pull” always yields “fatal: refusing to merge unrelated histories”).
And given that the sync only happens weekly, I wonder if the sources for versions of some of the components might be omitted entirely from the mirrors (what happens if a component is upgraded twice within one week?).
These issues were previously mentioned here in slightly more detail:
If you can’t share the internal repo, it would be helpful if at least the external repo could be made functionally equivalent. Having all of the tags brought over and applied to the correct commits would be helpful, and finding a way to mirror individual commits (minus the parts of the repo that contain closed-source code) would be even more helpful in restoring equilibrium.
You’ve had so few contributions because it’s been next to impossible to contribute even before switching to a private repository.
I think you might be surprised at the amount of engagement you would see from the community if AtlasKit was in a public repository, accepting pull requests with a public issue tracker.
I’m going to be fully transparent on the state of our external design assets, since I developed the Vendor Sketch Plugin and contributed to our Figma libraries (before moving to the Forge UI team).
The Vendor Sketch Plugin was always released as-is and with no promises of maintenance. I highly doubt it will continue to be updated as Atlassian has internally moved to Figma. However, it is mostly in sync with Atlaskit and should make a great basis for your own design libraries if you so choose.
We released Figma assets publicly, but it seems like we didn’t communicate this to the developer community. I am not on the Design System team anymore and cannot promise these will be kept public, or up to date.
I’d love if we could insulate the community from internal tooling like this, but this is one of the trade-offs I think we implicitly push on the Ecosystem, for better or for worse. I will reach out to my old teammates and see if they can communicate the release of the Figma libraries.
Thanks for the transparency @huw. As Remie said, this feedback is not directed to anyone individually. I appreciate the work that you did on the Sketch Plugin as it has saved me hours and hours of work. I’ve used it for quite a while before I moved on.
I was not aware that the Sketch Plugin was delivered as-is. At the bottom of the blogpost you linked it’s written that it’ll be updated periodically, so my expectation was that it would be kept up-to-date with developments within Atlassian.
I’m surprised to hear that Atlassian uses Figma internally. That must have been quite the change internally. Unfortunately it seems that this is not shared with the community at all. (unless I missed it somewhere).
The link to Figma assets you posted seems to navigate to the blogpost about the Sketch plugin. Could you see where we can find these assets?
The Figma libraries are in a kind of open beta state right now. I checked internally and the reason we haven’t announced any of this (the switch + the new libraries) yet is because we want to get them to a place where they’re complete and reliable (and we haven’t even completed the switch internally across every team yet). Expect a blog post soon, but these should be ‘ready’ ‘enough’ ‘for you to use them in the ‘’’’’meantime’’’’’’. (Don’t quote me!)
Hi everyone, let me introduce myself after lurking for a bit… I’m the engineering manager looking after the Design System team, based in Sydney (like most of the DS team).
I want to assure you all that we are still investing heavily in Atlaskit, the Atlassian Design System and our documentation. My team is as passionate about this as ever, and you can expect continued support and updated components. We’re here to make our experiences better for products, vendors and customers — this hasn’t changed.
I hear your feedback and I appreciate that we can improve how we communicate with you not just as consumers-at-large, but particularly as ecosystem partners. I understand that with a private repository, it’s not possible for you to self-discover what we’re working on, and we can’t rely on it as a communication tool as we did in the past.
We’ve had a few internal conversations in the last week about how we can support you, such as resolving licensing queries, and how to communicate about our plans — more to be shared on this. (Big thanks to @DanielDelCore for jumping in here on behalf of the team so far!) I personally plan to be more active here on CDAC in the future.
For a bit of context, the Design System team maintains the core, foundational components (the design-system packages), the design guidelines, and design tooling (e.g. for Sketch/Figma), and we work closely with the teams responsible for other packages, like Editor. That’s why we want to know the parts you’re looking at when you have a query, to direct accordingly (and ask for a little patience while we do so).
So please keep letting us know about specific queries. I’ll come back soon with updates, and hope to continue the conversation!
@JariSanders1 I’ve got to respectively disagree, while I wouldn’t turn down a bug bounty program, the amount of time Atlaskit has saved me when it all works has been pretty significant and when it doesn’t work, it was fairly easy to track down the issue.
So if I could raise a PR against the package and know it might get merged before hell freezes over, I would be infinitely happier vs knowing how to fix the bug and sticking it on their backlog with little to no hope of getting it fixed.
Hello! I might be a little late to the party, but I’m highly interested in this topic since we use Atlaskit extensively in many of our products.
Some of the components that have been lately released are hard for us to use. Like the ProfileCard, which seems to be aimed for a cloud-only environment (we share our UI between server and cloud apps).
And some of the components that are marked as internal-use only are very interesting for us, so we’re using them anyways. Like the user-picker, we use it a lot.
One of the things I’m concerned about is that there are two internal-use only components that we’ve been using listed in the deprecated packages list: Field Base and Input.
We use them because we have developed some custom fields for our apps, i.e: we have developed a colour picker using FieldBase and InlineDialog, and a Labels field combining Tag and TagGroup with the Select Field, FieldBase and the Input component.
I wonder if the reason to mark these components as deprecated is that you’re going to effectively remove them from the repository, or it’s only because we shouldn’t be using them.
On the other hand, it’s fair to say that we’re ignoring the rules, but we do really need to have custom fields beside the regular text, textarea and select fields currently provided. So, if Atlaskit provided a way to create custom fields with the same look & feel without having to write our own styles to match, that would be very much appreciated.
@stephenmok, can you elaborate on what soon means in this context? Given that it’s a relative term this may lead to different expectations. And I think proper expectation management is in order in regard to this topic.
I’ve been working with these Figma assets for a bit now and they’re quite impressive. I can definitely recommend anyone who’s still using Sketch to try Figma and these assets.
Thanks for your patience so far! It’s been a busy time as we, like teams across Atlassian, work through plans for the new financial year (starting next month). I’ll have more to share about the Design System roadmap after that is finalised.
In the meantime, here are key pieces we’re working on right now…
Specifically with the community in mind:
Preparing to move our public repository (the mirror) from Bitbucket to GitHub, where it will be available alongside other Atlassian open-source projects
Renewed investigation into whether we can change the licensing for icons to a more permissive license
And across the Design System for everyone:
Performance — We’re focusing much of our energy on an under-the-hood performance pass of each component, refactoring them specifically with performance in mind. We’re looking to improve SSR rendering (time to render and size of output), first contentful paint, time to interactive, interaction response times, and of course, bundle sizes. Range, Avatar and Spinner are the first components to get this treatment, with AvatarGroup, Tooltip, Flag and Button next up.
Navigation — As you may have seen, there’s a new horizontal navigation experience that has rolled out across Jira and Confluence cloud. This is something that we’ve been working on over the past few months, and we’re now optimising its performance.
Docs website — We’re building a revamped website that will bring together design guidelines and code documentation (what’s on atlassian.design + Atlaskit websites), helping avoid any inconsistencies between them. We’re also reviewing the existing content to make sure it’s right.
Bugs in the queue — We’ve started a new push to go and smash through our admittedly large backlog of bugs and small improvements in the service desk queue. You may have already seen some older issues get dug up and addressed!
As always, I’m happy to jump in to any specific questions (also feel free to tag me in new threads about the Design System). And expect to hear more in July.
As part of the performance pass mentioned above, we will be removing (in due course) deprecated components including Field Base, where we can better optimise their alternatives. Does Form and the form components themselves serve your needs? Input shouldn’t be used directly, so please don’t rely on it!
Hello Stephen,
Thanks for your reply.
Regarding FieldBase and Input, no, I don’t think we can replace them with just Form and Field. Those provide no styling for the fields. To make myself clearer, these are the components we’ve developed using them:
A “tags” field, which is a Select field with overridden components. Yes, we could be using the regular Select field as is, but we wanted it to look like an input (Select field has a grey background, instead of white), and wanted the options to look exactly like the Tag component:
And the least compromised one would be the ColourPicker, where we’ve user FieldBase to handle focus / blur states of the trigger:
I’m open to suggestions on how can we replace these components with safer options.
Thank you in advance.
@stephenmok, this return to “openness” is great news! One question and one suggestion:
Question: Does this mean that the source code to ALL components in the Design System will be made public (as was the case until 6 months ago), or does this apply to the more limited set of components on the design-system-mirror. For example, the source code for the Navigation components that you’ve just described disappeared 6 months ago… is it coming back?
Suggestion: Unless you are planning to commit significantly more internal resources and be willing to accommodate the demands of new, non-invested stakeholders into future versions of Atlaskit, I would absolutely NOT move the repo to GitHub. This is not a criticism, but, rather, a recognition of what the last few years of history plainly show: Atlaskit clearly serves internal Atlassian consumers first, ecosystem partners second, and the rest of the world, shall we say, “not so much”. This is not the way that open source projects on GitHub work.
For example, on GitHub, Palantir’s Blueprint, a close analog to AtlasKit, currently has ~550 open issues, with ~1500 closed, with about 3 new issues every day. A Palantir employee responds within 24 hours to every new issue, with an “owner” assigned to closing each issue within a specified number of days. That’s a huge commitment for any company to make.
If reaching the world through GitHub is your ultimate goal, you might want to first take the step of operationalizing collaborative open source processes with AtlasKit’s existing stakeholders on Bitbucket. If that succeeds and is economically viable, then consider GitHub.
Sean here from the Design Systems team at Atlassian (we build many of the core Atlaskit components).
For the examples you’ve mentioned:
Just use the @atlaskit/select component with isMulti (Atlaskit by Atlassian) You could customise the styles of the Input using props if you really want to make it look like a textfield, but in our design sparring our designers came up with a bunch of reasons to have it differentiated (along with the fact that browser defaults also differ the appearance of text inputs and select elements).
For the field-base colour picker, you can just use the native HTML5 colour input. We went down the road of building one, then realised the native ones are great (and accessible to boot). You can use one by simply passing type="color" to an @atlaskit/textfield, and tweaking the padding/max-width: nice-wilson-w0rcj - CodeSandbox
The Form and Field components that Stephen mentioned are more for structuring a nice semantic , and that’s how we also recommend handling the Labels/Names/Values/Validation for other field components (textfield/textarea/select/checkbox/radio/etc)
Thanks @scurtis .
We will be definitely work towards getting FieldBase and Input removed from our components. Regarding your recommendations, I really appreciate you took the time to think of alternatives, but:
We’re already using isMulti in the Select field, however we needed the options to look exactly like the Tag component, that’s why we overrode the Components prop following the doco of react-select to do so (React-Select).
The native color picker won’t suit our needs since it doesn’t work on IE11 (we share our frontend with both server and cloud apps, hence the need to support IE11…) but I guess we can do something about it or at least have some custom component that mimics FieldBase.
We’re already using Atlaskit’s Form and Field components to handle Form state and render labels, descriptions, error messages and stuff, but it still would be nice to have some common component or css class name to use for these cases where we need / want to implement some custom fields that require some special behaviour not supported by the current TextField component.
Hi everyone, please leave any comments you may have on this new topic related to Atlassian Design System and Atlaskit as I am closing this thread. Thanks!
