[Mid-fi-to-Code] Carbon to code plugin UX - Design + feedback 1

[kingtraceyj]

Acceptance criteria

Partner with Will for IBM Carbon Design to Code plugin user experience

User requirements:
See @RichKummer amazing notes below

Open questions:

• Will we need GDPR messaging? What kind of data are we collecting?
• How to incorporate metering (how does this affect GDPR messaging)?

---

Tasks

• Sketch UX flows based on user requirement list
• Playback ideas
• Consolidate design sketches
• Get feedback from Will

[kingtraceyj]

Step 01: Launch the plugin

• We should consider what type of onboarding we might need to make the function of the plugin clear. What’s the first time experience?

Step 02: One time configuration

• This second step involves pointing to the user’s Github repository and credentialing (if necessary).
• This should be a one-time configuration. Those will persist in local storage. Each subsequent run, they shouldn’t have to do that (unless the API key is updated).
• It’s possible that updates to the repo configuration may require the user to edit the settings to maintain the connection to the repo. We will need to provide a way to get back to settings and update if they need to.
• An example of the info needed:

GITHUB_TOKEN=YOUR_GITHUB_API_TOKEN
REPOSITORY_OWNER=YOUR_GITHUB_USERNAME
REPOSITORY_NAME=carbon (You shouldn't need to modify this. Fork the <https://github.com/carbon-design-system/carbon> repository to your Github account)
WATSONX_API_KEY=YOUR_WATSON_API_KEY
WATSON_PROJECT_ID=YOUR_WATSONX_PROJECT_ID
WATSONX_PROXY_SERVER_URL=http://localhost:3000/generate (Replace with URL to proxy server that calls watsonX ml/v1/text/generation API) 
WATSONX_PROXY_TOKENIZATION_URL=http://localhost:3000/tokenization   (Replace with URL to proxy server that calls watsonX /ml/v1/text/tokenization API)

• Need to consider the types of errors and success state that could appear here (need to be clear when the repo is connected properly).

Step 03: Running the plugin

Previously we thought the user would need to a default GenAI model, but this is no longer necessary.

Selecting a frame

• User can select a frame in the Figma canvas to run the plugin for. This can include frames nested inside other frames.
• Should be clear in the UI what the user is running the code generation against. Consider a preview of the frame as a visual or show the frame name. Do we only allow one frame to be selected at a time?
• Note that the teleportHQ plugin rates the usage of auto layout to highlight differences in the code generated. This might be a good enhancement – those spacing issues may not be obvious in a static canvas.
• We need to be cautious that the user doesn’t attempt to run on another frame and throw errors.

Running the code generation

• Once the frame is selected, the user can run the code generation.
• At launch, React will be the only framework supported, although this could expand in the future.
• A concern is that it will take time for the code to generate.
• The time is not predictable. It might take about a minute to generate the code, or it could take four minutes depending on time of day.

Consider showing a different loading state for different times.

• For example, using a progress bar if there’s a long load time (4 minutes).
• Can be dependent on how busy the system is

Displaying the generated code

• The plugin will show the generated code and enable the user to copy the results. We will also need to display an IBM legal approval disclaimer message.
• Milena Pribic is working on a pattern on how often to show an AI notice.

Rerun generated code

• It’s possible that the generated code may not be to the user’s liking. In that case, the user should be able to rerun the code generation without re-selecting the frame.
• If that is the case, need to be clear in the UI what frame the code is being generated against. What if the user selects another frame after the plugin is run?
• AutoHTML gives the user the option to open the generated code in a CodeSandbox or download a zip file of the code. Should we consider those options? A longer page may be a lot of code.
• User may want to validate the generated code before copying – what is that experience like in the plugin modal?
• Would the user want to revert back to previously generated code?

Other thoughts:

• At the start, we will only support React. Over time, we can add support for other frameworks, such as Web components.
• In the future, we may need to enable selecting a framework.
• For the design, there are a few example plugins we can explore more that enable code generation in Figma
• Article on Figma plugins created with Code Connect.

[kingtraceyj]

Drafts