Tips for Running a Remote Design Workshop

Advice from an Experience Design Lead

What makes a remote workshop so different? And how can you make it work for your team? A practical guide for running remote workshops – specifically design workshops – that work and deliver results.

Work from home policies and remote collaboration don’t need to put workshops on hold or detract from their value. But online workshop do you need to be rethought in a few ways to ensure the business outcomes are achieved.

There is plenty of advice available for those looking to run any kind of a virtual workshop but I wanted to talk to the special requirements for a design workshop. Below I will guide you through how to facilitate a remote design workshop so its most effective.

How are remote workshops different?

First, let’s talk about how remote workshops are different to in person workshops.

  • Reduced depth of conversation: intonation and body language carry significant amounts of meaning but these pretty much vanish during an online workshop. Even with videos turned on and good internet it’s easy to miss visual cues.
  • Increased levels of distraction: emails, text messages, Slack/Messenger/Teams, your dog in the room and learning new tools are all the result of not having a dedicated workshop space.
  • Reduced effectiveness of tools and methods: post-it notes and whiteboards take on different forms when online and sometimes these aren’t as effective as in-person.
  • Reluctance to actively participate: Creative teamwork takes trust and it can be difficult to build trust over a remote connection.

Advice for a successful remote design workshop

I’ve been running design workshops (in-person) for many years now but we recently ran a design workshop for a new client and I wanted to share the extra steps we took to ensure high engagement from all participants. Let’s dive into those now.

General Advice

  1. Prior to workshops, advise people to be on time, joining midway will derail the agenda for the group and usually ends up causing topics to be repeated.
  2. Organise a workshop assistant to lookout for participants who wish to speak that may be missed by facilitator. Facilitator may miss participant’s body language signs in the video grid while working with the tools, and they may also be unfamiliar with the introverts in the group. The workshop assistant should know all participants and encourage equal contributions from everyone in the group.
  3. I suggest that participants bring and use a mouse and not use trackpads for interactive workshops. We’ve seen some participants having issues with clicking and dragging items around on trackpads.
  4. I highly recommend participants connect to an external larger monitor if they are working on a laptop as it can help with viewing smaller details on the screen.

Miro-specific Advice

I’m a huge fan of Miro, a collaborative online whiteboard platform designed for remote and distributed teams. But if you are going to use Miro then I recommend familiarising yourself and other participants with the platform in advance of the design workshop. A few tips to help with this:

  • Tutorials are required for the first workshop participants.
  • Conduct an tool-familiarisation exercise to get participants to write their name on a sticky note then move into a designated area in a workspace.
  • An ice breaker is required for the first workshops to ease participants into doing workshop activities. We love a simple ‘price is right’ guessing game of three items which we prepared in advance. It’s not too hard, provides a little competition and fun without being so technical that some group members won’t be able to participate.

Running a remote workshop requires additional levels of focus and leadership to ensure engagement and participation from all attendees. To summarise:

  • Set up ice breaking activities
  • Over communicate
  • Set ground rules to reduce distractions
  • Ensure sufficient breaks to maintain engagement
  • Document using the tools that meet your workshop needs

Design: Your Questions Answered

Following on from our recent posts A lesson in design processes for 2020 and Design: But I still have a versioning problem, our design expert, Chung Sham is answering a few of your design questions.

Don’t see your question on the list below? Pop it across to and one of the team will send you a reply and update this post.

Let’s get into our Q&A with Chung Sham.

Q: You mentioned previously exposing design elements in Sketch. How manual is you needing to expose all of that stuff? The button does not have the font and the specific hex codes and all that sort of stuff. Is that something that you would manually do in Sketch?

Chung: No, there is no process or anything additional that we have to do as part of the design. Sketch, because it is a JSON-encoded file, is where it is getting all this information from. We just hit publish and InVision decouples everything. So, it is a smooth process. You can sort of see here with the text label, we have got the font family, the font size, all that sort of stuff, no additional work on our end.

Q: What you shared is an out of the box Sketch set up. Could you make your own  core style sheet page and then have your H1s and feed into your design?

Chung: The short answer is yes, you can set up a Sketch file and put all your H1s, H6s or your icons in a Sketch file and then have that in Abstract and push that into InVision.

The longer answer is that there are other tools available that will help with creating a design system, because then, once you have certain design decisions about why an H1 is the way it is or what fonts were chosen, you can put comments around it and expose that in more accessible way for a website or something like that rather than for Abstract, but yes, is the short answer.

Q: Thinking about responsive designs. If you are designing a component, you end up with different versions, one is for desktop tablet and another for mobile. Is that for just one design file? Does it actually have any tools to go? Okay, his container needs to drop it into the next slide. And can you do something like Flexi design or really? 

Chung: There are plugins that will allow you to set up Sketch files and build some of those smarts as you change, what we call in Sketch up boards, which is basically the working size of your design. You could start with a desktop, build in some of those smarts using a plugin, for example Anima. And then that will adjust the designs based on the breakpoints that you want. Now, that takes a little bit more work, obviously, because you do have to bake in those designs. So you are not just designing on that up board itself.

Another option is you could have multiple Sketch files at different breakpoints. And just like what you saw with Abstract in the second post, you can have those in different branches. Someone might be working on mobile, someone might be working on desktop. There are a few different ways you could manage that, and every team in every organization is different, but there are ways to do that. 

Q: If we end up having multiple Sketch files for different breakpoints because technically, some of those can be not achievable. For example, some designers just go crazy and then just move stuff around in mobile, not making it responsive. This increases the complexity of development. Do you come across any of these challenges and how did you sort of overcome them?

Chung: Yes. So that comes down to, I suppose, the design practice and the designer themselves. What you saw before is the way to manage those design decisions. I think the example would be that you would have three different uploads, freedom files because that just visualizes how certain elements or components should behave down to different breakpoints. And you can share those with the client as well. Whereas if you do bake it in and inside Sketch, you do have to change the artboard within Sketch to be able to see how that behaves. So a lot of times, it is a lot easier for clients to visualize how these three different breakpoints look like and then have comments be placed against it in something like InVision.

Q: Our designers might have ideas around placement. Do you see that more as a collaborative experience between technical and the designer team to go, “Yes, we have worked together to produce this design but there could be technical difficulties and we might need to sort of, it goes kind of both ways.”

Chung: There are a few different deliverables that we designers like. If it is quite a complex component, you might want to start off with a discussion with the developer first, create a wireframe, have a discussion around how that actually behaves before creating a high fidelity version that you would see in Sketch. This is what I’d call design practice for the individual designers, rather than the tools to help solve that. 

Q: Let’s say you have a senior designer on the project. Then you bring in more junior designers who are still onboarding and still learning. Do these tools have any provision for you as the lead creative person to place restrictions on things or warnings, let us say? I guess you’d call it an approval workflow but for alerts.

Chung: There is no out-of-the-box function that might facilitate that in Sketch, it will be a lot of basically, communication. But Abstract would be a place where – such as the request review –  so if they complete a task, send a request review to whoever the senior lead is and then they can actually see and edit that file if they need to or send it back to the junior designer before merging it back into a brand new milestone.

And we are starting to see plugins for Sketch where if a designer enters a different font, it will say, in real-time, “Hey, this is not part of the design.” But that is still in its infancy, but it is moving towards something like that.

Don’t see your question above?

Pop it across to and one of the team will send you a reply and update this post.

Design: But I still have a versioning problem

Following on from my recent blog post, A lesson in design processes for 2020, I wanted to address versioning in design.

Design working shifts are history

Sketch files are managed locally and we still have the problem of how to manage versions on different people’s machines. 

For example, you could try design working shifts. You might have Jane, who will work on the website file from nine to twelve and she will make edits to a couple of banners but Jim will work on the website after that from twelve to three because he is going to make changes to the footer. But then Alice might need to work on the main navigation and she will take that from three to six.

This isn’t good enough. We need something that is better able to:

  • Manage our files.
  • Work together in parallel. We do not want to work in design shifts.
  • Preserve the thinking and history of designs because clients might ask for something and we will make a change, but then another designer might be freed up and they will jump on board the project but they might not know the history or the context that they are jumping into and make changes that aren’t based on current information.
  • Communicate and collaborate
  • Scale: onboard new team members, preserve team knowledge and have context around all design decisions

This is where Abstract helps

Abstract is one place to manage your design versions and collaborate in the one platform.

We have borrowed certain concepts like branches, you have got master. We also have merge branches as well. And of course there are tools around that offer version history, but in terms of version history and version control, it is not exactly the same.

A quick definition: version history vs version control

Version history is still working on a single timeline, and this sort of goes back to that design shifts problem mentioned in our first design blog post. What we really need is version control where multiple designers can work on different branches and they can’t intermingle with other people’s work. And then, we merge that back into the master file after we have all decided which ones meet the requirements.

Until now, designers have mostly been working with version history. Version control is common for developers but is a very new but powerful concept for designers.

Quick recap of the benefits:

Single source of the truth

  • All work is located in one place can accidentally be overridden or lost.
  • Master files, they are all centralized.

Parallel design

  • Multiple designers can work on the Sketch files without overwriting each other’s works.
  • Designs are branched, committed and merged.


  • It is no longer my file. It is our files.
  • All design work is visible, and you can track progress and changes, as well as see feedback and understand context.
  • Designs can be reviewed and approved before merging.
  • Create a smoother transition from design to development.

Check out the next blog in the design series: Design: Your Questions Answered.

A lesson in design processes for 2020

Today, I’m talking about the tools and processes in a design process, and I’m going to specifically cover the past and present of design processes.

Exposing design tools and processes can improve collaboration, provide a smoother transition from design to development and provide insights into how designers work. Because there’s no point building a bridge from two sides if they don’t align once they reach the middle.

What design used to look like

In the beginning, there was only Adobe Photoshop. A traditional process would have seen a designer send JPEGs to a client because the Photoshop file was too large to share. In response, the client would provide feedback in a Word doc and the designer had to muddle through trying to align the design in Photoshop with the client’s amendments. Versioning and latest files became a problem. As a consequence, the aesthetic output was impacted.

Keep in mind that Photoshop was designed and built around photography rather than graphics. It sort of did the trick when it came to web design, in that you could draw some stuff and put some text into your designs but in reality it wasn’t meant to be a digital design tool. It wasn’t designed first as a digital design tool.

A smarter working environment for designers

What we needed was a smarter working environment built from the ground up specifically for user interface design or digital design.

What designers really needed was:

  • To expose the structure of design work
  • More optimised files, faster to open and easier to share

Along comes design tools such as Sketch…

…and InVision.

But what is Sketch? An app built for digital design. It is a local application on a Mac. Edits are non-destructive, so that is different to how Photoshop works. If you want to redraw a shape, you would have to start all over again, and you cannot really change things as easily as what you would be able to do in Sketch. Much smaller file sizes; we are talking about megabytes here. You could have files from ten megabytes, twenty, but certainly, we are not talking about five hundred, unless you add large raster graphics or photos in there. The documents are stored as ZIP archives. The Sketch file format is actually just encoded JSON data. That allows for better third-party integration to plugins or other platforms such as InVision. There is a whole bunch of plugins, and Sketch is super-fast compared to Photoshop.

But where does InVision fit in? It is a cloud-based hosting platform for designs. The reason why you would want to combine InVision and Sketch is it allows you to create interactive prototypes.

It is a shared environment for collaboration. You can put comments in context, and we can share these screens out to clients. There is also smart outputs, but why we want that is developers can inspect the actual structure of the designs and also get creative assets like SVGs from the actual design files itself, rather than send it by email or zipping it up as what we used to do back in the day. So, it is one place to host all your designs.

Example 1: No such thing as dumb JPEGs anymore

Let’s say you draw a shape in Sketch. It is 212 pixels wide, and it is 212 pixels high. I can change that to, let us say, 200 pixels and it would just change dynamically. Now, it is smart in a way that these fields are not just inputting values. Sketch recognizes some conditions as well. So, let us say I wanted to make this with an extra 100 pixels wide. I could type in 300 pixels, but instead, there are calculations. I could do +100, and it will make that three hundred. I do not have to actually know what the end result is. I just need to know what I want to add to it. Just like with plus, you can also minus as well.

It also recognises different commands. For example, I might want to add 100 to the left only so I add a letter, say ‘R’ and that locks the Right side. The shape them adds to the Left side only. You can measure and have consistent spacing, which is really good for designers because we do want to have consistent spacing for certain elements to match up to a grid.

These are all decisions that we have been baking into the designs.

This is all living on my local drive but how do I share that?

There is a little plugin that InVision has made called Craft. I have made a prototype called, “Awesome Website,” and I can go and publish. That goes off into the cloud and will publish this image into that project.

For example, I have this component called, “Hero Banner” and I have got the modal in here as well. If I click into the Hero Banner, anyone that has the shareable link will able to see this banner. 

But did you know this isn’t just a flat image? We can create an interactive prototype from this file and clients and anyone with the shareable link can start adding their feedback. No more Word docs back and forth! Simply, click on a spot (aka hotspot) and add comments. Now those comments are a part of the project and there is context. In turn, a designer can return to the file, know straight away what is being asked of what, go into build mode and implement the change.

The designer then returns to Comment mode and hits resolve to say, “Yes, that is done.” We can track all the history of this, and all the design decisions.

Quick tip: This is not just a JPEG image for developers as we do have an Inspect mode. You can expose many different design elements, for example:

  • What is the width
  • What is the height
  • What is the grid width columns and the gutters
  • There is also the colours
  • If there are any assets available for download
  • The structure of the pages and the layers on the left here
  • There is an image, a background, content too

You can also grab the code. It is not just a dumb JPEG image, there is a whole bunch of code that gets pushed up through into the cloud and gets decoupled. You can also change what the code is. For example, you want to use less SAS objective-C Swift code as well. It is all in here. So depending on what the project type is, you can switch that up yourself.

Example 2: No such thing as dumb JPEGs anymore

Let us say we go to any website (but today let’s say that website is, grab a screenshot. We’ll then copy/paste the SVG image into Sketch.

Because this is a smart working environment, it is not a static or dumb image. In Sketch you’ll see all of the exposed different elements from the screenshot: colours, texts, font sizes, etc.  

Next in our design series, I’ll be talking versioning control.

Chapter 4: Deploy Sitecore into Kubernetes (AWS EKS)

Sitecore now has official support of deployments into kubernetes. This is a guide of what’s involved in deploying Sitecore into kubernetes (Tested with AWS). Download the Sitecore container deployment and extract the relevant (xp / XM) configuration files to a working folder.

Prepare certificates

Prepare the certificate (.crt) and private key (.key) files for content management, Content Delivery and Identity Server roles and copy them into the relevant folders as per below screenshot.

Mutli-Site configuration

If you have a multi site implementation you might need to create a separate folder for each domain name under the tls folder and copy the relevant cert and key files and update the Kustomization.yaml

Update the ingress configuration (ingress.yaml) with the domain names to content delivery as per below

Prepare and deploy secrets

  1. Update the database passwords in secrets folder text files and change the usernames if you have modified the database usernames.
  2. Generate 64 character keys for telerik encryption, identity secret and reporting api key and update the relevant text files
  3. Create a x509 certificate for identity server to be used for signing credentials and update the identity certificate and password text files. (sample)
  4. Update the license text file with base64 encoded string of the license file (sample)

Once the secret files are all prepared, run the following command to push the secrets into kubernetes environment.

kubectl apply -k ./secrets

Deploy external services (optional)

There is a option to use services like SOLR, Redis and SQL in containers for a non-prod environment. It is not recommended/supported to use these in a production environment. To deploy these external services run the following command

kubectl apply -f ./external/

Wait for the new pods to be in Running status. Use kubectl get pods -o wide -A to check the status of the external pods.

We would need to deploy the initialization jobs to finish setting up the SOLR and SQL pods. The default job configurtaion files provided by sitecore are missing the node selectors, so there is a chance that these jobs end up on linux nodes and fail or get stuck on ContainerCreating status. Add the below snippet just above imagePullSecrets under spec into both solr and mssql init job YAML files (in ./init folder)

      nodeSelector: windows

Run the following command to deploy the init jobs into the cluster.

kubectl apply -f ./init/

Wait for the jobs to return a Completed status, Use the get pods status command used previously.

Deploy Sitecore and Ingress configuration

To deploy sitecore and the nginx ingress configuration run the following command

kubectl apply -f ./ -f ./ingress-nginx/ingress.yaml

Wait for the deployments to be completed and all pods to return either a Running or a Completed status and Sitecore should now be ready.

Check out the other related posts:

Sitecore on AWS Kubernetes (EKS)

Chapter 1: Configure AWS and Kubernetes CLI

Chapter 2: AWS Kubernetes Cluster for windows workloads

Chapter 3: Deploy nginx ingress controller into AWS EKS Cluster

Chapter 3: Deploy nginx ingress controller into AWS EKS Cluster

Ingress controller is used in kubernetes to direct external traffic to the relevant containers/pods running in the cluster. nginx is a very common and popular ingress controller used with kubernetes. This article guides through the steps involved in deploying nginx ingress controller.

Install helm

helm is one of the popular ways of managing deployments into kubernetes environments. Use the below chocolatey command to install helm.

choco install kubernetes-helm -y

Register Repositories to helm

Add the default repository to helm using below command.

helm repo add stable

Add the bitnami repository to helm using the below command

helm repo add bitnami

Once the above repos are added to helm. Search for nginx using the below command to ensure that we have pulled the latest nginx charts into the repository. Use the below command to search

helm search repo nginx

Deploy nginx ingress controller

Run the following command to install bitnami nginx controller on to the default linux nodes in the cluster.

helm install <deployment-name> bitnami/nginx-ingress-controller `
--set replicaCount=1 `
--set nodeSelector."beta\.kubernetes\.io/os"=linux `
--set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux `
--set-string controller.config.proxy-body-size=10m `
--set service.externalTrafficPolicy=Local `

Retrieve external ip for DNS

Run the following command to check the status of the ingress controller apps deployed into the cluster. Wait until the status changes to Running.

kubectl get pods -o wide -A

Run the below command to get the external ip of the ingress controller in the cluster. This returns a cname which can be used for managing the DNS entries going into the applications running in the cluster.

kubectl --namespace default get services -o wide -w bitnami-ingress-nginx-ingress-controller

Note: If you are working with a dummy DNS names you can perform a nslookup on the CNAME and extract the IP Address to add them to your local hosts file with the relevant host names.

Check out the other related posts:

Sitecore on AWS Kubernetes (EKS)

Chapter 1: Configure AWS and Kubernetes CLI

Chapter 2: AWS Kubernetes Cluster for windows workloads

Chapter 4: Deploy Sitecore into Kubernetes

Chapter 2: AWS Kubernetes Cluster for windows workloads

AWS has been supporting windows workloads in kubernetes since march 2019. The default cluster created only supports linux workloads, this article is a detailed account of how to create a kubernetes cluster in AWS for windows workloads.

Create Cluster

Create a new EKS cluster using the below command. This command creates the default nodes that have to be linux. These nodes host the default applications (pods) that manage the orchestration of kubernetes. Please ensure to update <Cluster-Name> and <Node-Group-Name> and adust the number of nodes accordingly. Its a good practice to have at least 2 nodes to ensure the high availability.

eksctl create cluster `
--name <Cluster-Name> `
--version 1.17 `
--nodegroup-name <Node-Group-Name> `
--node-type t3.medium `
--nodes 2 `
--nodes-min 1 `
--nodes-max 3 `
--node-ami auto

Export Kube config

Run the following command to export the kubernetes cluster configuration into the user profile so the context is set for kubectl

aws eks --region ap-southeast-2 update-kubeconfig --name <cluster name>

Ensure that all the default pods are in running state using the below command.

kubectl get pods -o wide -A

Install VPC controller

Install vpc controller to support windows nodes in the cluster using the below command.

eksctl utils install-vpc-controllers --cluster <Cluster-Name> --approve

Run the get pods command again to see the VPC controller pods running as per below and wait until all the pods are in Running status.

Create windows nodes

Create a node group with windows nodes to support windows workloads using the below command. Please update the <Cluster-Name> and <Node-Group-Name>. Adjust the number of nodes according to the need.

eksctl create nodegroup `
--region ap-southeast-2 `
--cluster <Cluster-Name> `
--version 1.17 `
--name <Node-Group-Name> `
--node-type t3.large `
--nodes 2 `
--nodes-min 1 `
--nodes-max 3 `
--node-ami-family WindowsServer2019FullContainer `
--node-ami auto `

Check the status of all the nodes running correctly using the below command

kubectl get nodes -L `
--sort-by=".status.conditions[?(@.reason == 'KubeletReady' )].lastTransitionTime" `

Check out the other related posts:

Sitecore on AWS Kubernetes (EKS)

Chapter 1: Configure AWS and Kubernetes CLI

Chapter 3: Deploy nginx ingress controller into AWS EKS Cluster

Chapter 4: Deploy Sitecore into Kubernetes

Chapter 1: Configure AWS and Kubernetes CLI

AWS supports kubernetes workloads for windows through EKS and also supports use of command line interface for deploying and configuring resources. Using CLI makes it easy for automating this process through a CI/CD pipeline when required. This article guides through the configuration of CLI for AWS and Kubernetes.

Install and configure AWS CLI

Install AWS CLI using chocolatey

choco install awscli -y

Once successfully installed run aws --version to check if the cli is correctly installed.

Configure AWS CLI with the relevant access key for CLI. This can be generated using the My Security Credentials page through AWS Console. (detailed instructions)

Use the below command to start configuring the CLI

aws configure

Install CLI for EKS

eksctl is the command line utility used for managing the EKS cluster. Use below chocolatey command to install eksctl

choco install eksctl -y

Once successfully installed run eksctl version to verify the version (see below)

Note: eksctl seemed to only use default profile. If you are using named profile for aws cli. this will always use default profile. Hopefully in the newer versions of the cli this will be addressed by AWS.

Install CLI for kubernetes

Install kubectl using chocolatey using the below command

choco install kubernetes-cli -y

Check out the other related posts:

Sitecore on AWS Kubernetes (EKS)

Chapter 2: AWS Kubernetes Cluster for windows workloads

Chapter 3: Deploy nginx ingress controller into AWS EKS Cluster

Chapter 4: Deploy Sitecore into Kubernetes

Sitecore on AWS Kubernetes (EKS)

Sitecore with release of version 10 now officially supports deployments into container workloads using kubernetes. Sitecore has officially marked PaaS would be deprecated in the future releases (more details). This article is about how to deploy Sitecore 10 into AWS kubernetes (EKS). This article is broken down into four chapters as per below with a brief summary.

1. Configure AWS and Kubernetes CLI

AWS command line interface could be used to create or manage resources in AWS. This chapter guides through the installation and configuration of AWS CLI and Kubernetes CLI. Click here to start configuring your CLI.

2. Create AWS Kubernetes Cluster

A Kubernetes cluster needs to be provisioned to deploy Sitecore workloads. This chapter guides through the creation and configuration of AWS EKS Cluster. Click here to start provisioning the cluster.

3. Deploy ingress controller into EKS Cluster

An ingress controller is used to create external access to the applications deployed into the Kubernetes cluster. This chapter guides through the preparation and deployment of ingress controller. Click here to start deploying the ingress controller.

4. Deploy Sitecore into AWS EKS

This is the last chapter that guides through the preparation of the configuration files and deploying Sitecore into kubernetes cluster. Click here to start deploying Sitecore.


Credit to Gurpreet (Garry) Singh & Jason Umiker for sharing their knowledge and expertise on AWS EKS.

Aceik Announces Platinum Sitecore Implementation Partner Status

Today, the Aceik team is excited to share our new status as a Sitecore Platinum Implementation Partner.

Sitecore is the global leader in customer experience management software and this promotion recognises the partnership between the two companies and the commitment to deliver outstanding customer experiences through the use of the Sitecore platform.

Platinum Partners are recognised for their deep knowledge of Sitecore, thought leadership and best practices in delivering flawless customer experiences at scale.

Jason Horne, Chief Executive Officer at Aceik said, “This is the highest-ranking tier of partner status in the Sitecore network, and it is a recognition of the success and expertise Aceik’s team has demonstrated for our customers across the full breadth of Sitecore products.”

It has been a busy year for our team

In recent months, Sitecore recognised Aceik’s contribution to the Sitecore community with two Most Value Professional status and a Sitecore Experience Award Honorable Mention.

Aceik’s CEO, Jason Horne was recognised as a Sitecore Technology MVP for a fifth consecutive year alongside colleague, Thomas Tyack who was named Sitecore Technology MVP for the second year in a row.

Aceik was awarded Sitecore Experience Award (SEA) Honorable Mention in the Most Sophisticated Implementation category for its work with customer, RAA.

Last month, Aceik appointed Wayne Vickers, former Head of Customer Experience for the Australian Football League (AFL) as Chief Operating Officer and Creative Director.

The new hire demonstrates Aceik’s continued commitment to its Sitecore clients, as well as the Sitecore partnership.