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.