Nov/Dec 2018 Atlassian Design Community meet up - server design & front end update

ecosystem-design-meet-up

#1

Hello friends!

Our next ecosystem design community meet up just over a week away!

This month we’ll be hearing from our server design and front end team about their recent decision to converge the Atlassian Design Guidelines (ADG) for server and cloud.

Alex Skougarevskaya, design manager for the Atlassian design systems, will be presenting on the details of the decision and how it affects you. We will have plenty of time for Q&A with her and other members of the team. We would also like to take this time to understand how we can best support you.

This meet up will be a video call on the 22nd of November, from 10:00 AM till 11:15 AM CEST.
Google hangouts call link: meet.google.com/fdc-yvwa-rmm

I know this time doesn’t work for everyone, I’m sorry. Rest assured it will be recorded and posted on the developer community. We’re also considering doing this topic again in a US friendly timezone, if you’re interested in that please let me know.

If you have any questions please reach out to Natalie (njohnson2@atlassian.com), Lucy is going on holiday. Feel free to forward this invite to your colleagues, tell them to add their emails here to receive invites to future meet ups.

Looking forward to seeing you online soon!


#2

I’m hoping I’m misreading this but does this mean that AUI is dead? If so, when will this be hitting the server products? What’s the deprecation period of AUI?


#3

Does this mean that there are now plans to migrate server products away from AUI and to an AtlasKit/React frontend? We are currently looking at migrating one of our server apps to React, which would be great timing if this coincides with Atlassian doing the same.

I’m sure this will be covered in the meet up, my concern is that currently I’m building a new UI for one of our products with React/AUI, perhaps we should just be using AtlasKit to save ourselves the work of a migration later on if Atlassian moves Jira Server to AtlasKit.


#4

Hi all! This sounds like a huge change that will have many implications. Will any members of the server product teams be present too? Particularly those who will be able to speak as to how this is expected to fit into P2?

I’m also very interested in a US-timezone-friendly session (versus getting up at 4 am!).


#5

Hey all!

I’ll spend some time on this stream expanding upon the technical aspects of these design changes. We will also arrange a future date to have a dedicated stream for the technical aspects of them. In the meantime, I’ll answer a few questions here:

I’m hoping I’m misreading this but does this mean that AUI is dead?

AUI is not dead. AUI is still in heavy use in our Server products, and will likely be for many years still. AUI will continue to be maintained through FY19 at minimum.

What’s the deprecation period of AUI?

AUI doesn’t have a sunset date – it’s way too early for that. See my above answer.

Does this mean that there are now plans to migrate server products away from AUI and to an AtlasKit/React frontend?

Server product teams are exploring use of Atlaskit as their UI component library of choice when implementing new UI.

AUI will still be in use in the short- and medium-term.

When will this change be hitting the server products?

A complete migration to use of React and Atlaskit will be a multi-year journey across all the products. There will be multiple requirements and milestones along the way. Expect to see each product team start this journey at different times.

Each product will engage with its ecosystem at each stage of its journey.

What’s the rollout strategy?

A full description of the rollout strategy is best saved for a dedicated discussion. For the moment, some quick points:

  • Initially, this direction should only apply to completely new features.
  • Existing UI will remain as-is in the short-term.
  • Timeframes for changing existing UI will vary from product to product.
  • To reiterate, each product will engage with its ecosystem at each stage of its journey.

How is this expected to fit into P2?

It is possible to push React and Atlaskit in to a P2 plugin. While I don’t believe there is official Atlassian documentation on how to achieve this, several vendors within the community have posted and published how they have achieved this:

Over time, as each product team moves along this journey, we will publish more in the way of tooling and patterns to help.

Perhaps we should just be using AtlasKit to save ourselves the work of a migration later on if Atlassian moves Jira Server to AtlasKit?

Both AUI and Atlaskit are implementing the Atlassian Design Guidelines. Expect them to align in aesthetic and behaviour over time.

You can use either AUI or Atlaskit to build your product’s UI. The libraries have different consumption stories, but both are valid choices.

Will this change adversely affect my app?

As much as possible, we don’t want the core product team’s choice of component library to affect plugin vendors’ choices. This isn’t always the case given the way that Server products’ UI layers work today, but it is what we are aiming for.

As I mentioned in the previous answer, this will be a multi-year journey, with multiple requirements and milestones along the way. Doing what can be done to ensure apps are not adversely affected by the core product’s UI component library choice will be one.

Will any members of the server product teams be present too?

I will be on the call. Mostly, I will be re-iterating the points above, but I’ll be available to take further questions you may have.


#6

Got questions for the server design and front end team? Submit themhere so we can make sure we answer them during the meet up. We will also be taking questions live on the day.

Given the interest on this topic we will be running the same meet up in a US friendly timezone after the thanksgiving festivities. Watch this space for updates on the time/date of that call, or add your email address to our mailing list to receive an invite.

See you online soon.


#7

Thanks for the clarification daz, exciting times ahead for server products!


#8

@ldenton, is it OK if I pose my questions here? The Google Form link accepts one line of input only and my thoughts were too bit to fit. :slight_smile:

@daz wrote:

How is this expected to fit into P2?

It is possible to push React and Atlaskit in to a P2 plugin. While I don’t believe there is official Atlassian documentation on how to achieve this, several vendors within the community have posted and published how they have achieved this:

I’ve been working with React+AK on P2 for the last year and a half or so, and I have some thoughts/questions to share based on that:

  1. Are you expecting that apps will be deployed exclusively in iframes, or will they be running within the host page?
  2. If within the host page, this raises a number of concerns. Currently, apps typically reuse the host-provided AUI to render their content, which makes them skinny. With React and AtlasKit, the apps can certainly ship with self-contained AtlasKit and React packages themselves (admittedly very convenient). Alternatively, the host product could publish some of these components. But there are concerns on both sides:
    a. If each app is bundling React+AtlasKit, any reasonably-sized app is going to be pushing a 1 Mb+ bundle. If you have a dozen of these apps deployed in a global scope (or, say, in web-panels somewhere) then this produces fat pages quickly and it seems like it becomes unmanageable at scale.
    b. If the apps will reuse components and you are expecting the host product to publish them, then this raises questions like: (i) How will the apps consume them? (ie. require-ing AMD resources? Individually?!) (ii) We will need some guarantees of API stability at a component level, since now apps are dependent on the specific versions of AK components that are installed on the host. (iii) We ship one JAR for many host product versions (generally going back two years), so even if you were to start bundling React+AK on the host immediately, we couldn’t necessarily use it directly. Some sort of compatibility library that we can bundle will be necessary.
  3. Once everyone starts shipping React+ES6/7 stuff on the same page, concerns arise in terms of polyfills. Most transpilers seem to require that you ship some global-scope polyfill for their generated code to work, and if everyone is doing this, I can see problems surfacing quickly. It’s great if the host products were guaranteed to ship with some basic level, but that doesn’t solve all of the problems:
    a. The polyfill I need/want today in 2018 is probably different from the one I’ll need in 2020. Some way to incrementally add new polyfills seems essential. (Currently, things like babel-polyfill will refuse to install themselves twice, so if Jira is shipping an old version of the polyfill.) Or else we need approved ways to customize our build environment so that polyfills aren’t needed (a custom babel transformer, or…?).
    b. It seems like a compatibility library would also be helpful here, to ensure that all vendors are working off the same sets of polyfills and that things are not in conflict. Remember that we’ll need to ship the same JAR to work with host products that don’t include anything yet, so this library would need to be something that we can bundle.
  4. We ideally need a dedicated plugin module type. Getting everything to work together right now is a logistical hassle, because P2 wasn’t built with React in mind. For example, before you can mount your very first component, you need to set up a webwork action module, create a webwork action class (that does nothing!), create a Velocity template that slots the ReactDOM mount point into the right point in the page decorator, #require a web-resource, and finally create a web-resource that serves up your React entrypoint. It would be nice if we had the following instead (with bonus points if there is a bundle-able compatibility library that allows us to ship against older product versions):
    <react-page url="/foobar.action" entry="js/my.webpack.bundle.js" pageDecorator="administration" />.

I know that these are the early days of the project and that this is the very first call, so I imagine that you may not be able to answer questions at this level of detail yet–but I am putting them out nonetheless in the hopes that you may be able to consider them while making design decisions. (I recognize that some of the questions might be more in scope for the product-specific teams rather than the design team!)


#9

Hi @ldenton. Just wanted to quickly echo @scott 's feedback.

1st regarding having a US friendly call. 4am on Thanksgiving day was definitely not going to work for our crew here in the states either. :turkey: :wink: Thanks again for your understanding and preparing another session. There is certainly a great deal of interest in these design focused topics here in the states, so it would be wonderful if we could plan for US-friendly meeting options driving ahead as well if at all possible please. More interest is definitely a good problem to have, so I’m sure we can all work something out. :slight_smile:

2nd regarding the google form-based question format, a humble recommendation would be to instead keep questions/answers open and transparent in a format like this (as @scott has expanded upon here). It’s helpful for all teams in the ecosystem to gain a richer appreciation of the challenges facing their peers by participating in the conversation as those challenges develop. Especially when it relates to meaningful changes on the horizon. While not all teams may join the calls themselves, many follow conversations like this one. Again, just our humble two cents.

At the end of the day, even though the road may be a challenging one, a long term drive to a unified front end experience is likely in everyone’s best interest, including the customer’s. Looking forward to learning more during this next round of sessions.


#10

Hi @scott, thanks for your detailed questions and thoughts. I agree with your assessment of the situation and tradeoffs. I have thoughts on how the technical aspects will work over time, but we’re diving really deep in to the implementation details here, which means we’re very far off-course for what the design team are hoping to discuss. I’d recommend we split this in to a separate thread to continue the discussion there.


#11

Hey guys,

Could you please paste the link here when you’ve got the recording ready?

Thanks.


#12

Hi all,

Here is the link to the recording.

Cheers!
Natalie


#13

Hello all,

Thank you to everyone who joined us a couple of weeks ago for our November meet up. As promised, we’re hosting a repeat of this meet up next week in a US friendly timezone.

This meet up will be a video call on Tuesday the 18th of December, at 9 AM PST .
VC link: meet.google.com/cey-midm-cux

I know this time doesn’t work for everyone, I’m sorry. Rest assured it will be recorded and posted here. We also have a recording of the November meet up here if you would like to watch that.

To refresh your memory, we’ll be hearing from our server design and front end team about their recent decisions around ADG server and cloud. Alex Skougarevskaya, design manager for the Atlassian design systems, will be presenting on the details and how it affects you. We will have plenty of time for Q&A with her and @daz . We would also like to take this time to understand how we can best support you.

If you have any questions please reach out here or via email (ldenton@atlassian.com). If you would like calendar invites to our meet ups in the future, please add yourself here to receive invites to future meet ups.

Looking forward to seeing you online soon!

The Ecosystem Design Team.


#14

Hello again all,

Thank you to those who joined us yesterday for the US version of this meet up. You can find a recording of yesterdays session here, and a recording of the previous session here if you’d like to watch both (it’s more or less the same presentation but different questions from the audience).

If you have any more questions please feel free to comment them in this thread and we’ll get back to you. As we have more to tell on this topic we’ll continue to update the community, so stay tuned! Also keep an eye out for our next meet up early next year – I’m taking topic suggestions!

Happy holidays everyone. See you in the new year!

Ecosystem design team.


#15

Thank you very much for the content in both meetings, we now feel confident in pushing forward with AtlasKit in our apps for Jira Server.

As Atlassian moves to a single ADG implementation, is AUI going to be updated to try to align its design with the current offerings of AtlasKit?

Currently forms/dialogs/tables in AtlasKit differ from what is offered by AUI, will AUI be getting updates in these areas?

We will be writing all our new UI code with AtlasKit, but we’d like to try and retain some similarity between the legacy UI we have and the new one.

I guess one path for us could be moving some of our legacy UI code to the reduced UI pack, eventually we will rewrite in React but maybe the reduced UI pack is a good shortcut for updating old UI with minimal code changes?


#16

Hi @reece, excellent questions!

As Atlassian moves to a single ADG implementation, is AUI going to be updated to try to align its design with the current offerings of AtlasKit?
Currently forms/dialogs/tables in AtlasKit differ from what is offered by AUI, will AUI be getting updates in these areas?

Yes, the design of AUI is planned to align with that of Atlaskit / ADG as we progress. As you may have seen over the course of FY18, the design in AUI has already aligned a whole lot. We’re aiming to have near-parity of design across both libraries, with a few caveats.

The AUI and Server design teams have updates planned for forms, focus styles, tables, and some other components. However, given the wide breadth of usage of these components and the scope of impact they would have, these components require a more cautious rollout – we don’t want to force products or plugins to “stop the world” in order to react to the design of these components changing. This specific topic deserves a bit more unpacking, so I’ll split it in to a separate discussion and update this post with a link to it once I have.

I guess one path for us could be moving some of our legacy UI code to the reduced UI pack, eventually we will rewrite in React but maybe the reduced UI pack is a good shortcut for updating old UI with minimal code changes?

If your old UI is implemented in AUI, it can stay as that. AUI isn’t going away! It will continue to work for you, and as per the answer above, should eventually satisfy the ADG aesthetic.


#17

Thank you for the clarification :slight_smile:

I can see that trying to push out updated form/table styling to AUI would impact all products/apps significantly and can’t be done without some prior notice and discussion.

It is good to know that Atlassian are planning updates in these areas, as we start using AtlasKit more in our product things start to look “odd” when compared to other parts of our app that are AUI based, forms being the big one at the moment and to a lesser degree modals which look slightly different.

I guess Atlassian will improve this by bringing AUI inline with AtlasKit, so that when new AtlasKit based features come to server they do not feel out of place in an otherwise AUI based UI.