Enhancement: UX Improvements to the sidebar panel/tool window

[T3sT3ro]

Is your feature request related to a problem? Please describe.
The UI of sidebar could be improved for better readability and UX. Right now some elements/views are redundant, occupy much space (forcing user to scroll) and separate elements that should be grouped together.

1. First, a little inconsistency: The view widget used in the sidebar in the current FM extension seem to differ from the regular view widget used in other extensions (e.g. the "Explorer" sidebar). The differences between FM's sections and Explorers sections are:
   • FM's views don't animate when opened/closed
   • FM's views are not tab/keyboard navigable (space to activate, arrow up/down to move focus)
   • FM's views aren't separated with a horizontal divider (border?) while section in the Explorer are
   • FM's views can't be reordered with drag and drop.
2. Secondly, the "Actions view" together with "Other Actions view" should be moved to View Actions. Any user-defined actions should also display in here as well instead of the separate view.
3. The third thing is about UX and readability: the ordering and grouping of views in the toolbar could be adjusted.

Describe the solution you'd like

1. To address the first issue: Use official VSCode views and follow their guidelines.
2. For the second and third one, here is a detailed list:
   • Remove the "Actions" and "Other actions" sections, move them to appropriate places using default vscode icons when applicable:
     • Don't show the name of the file in the primary sidebar of the extension. That's what the tab pane is for. Without the filename there will be more space for actions
       
     • Keep only one "Open Dashboard" action in the Sidebar toolbar (there are now 3: one on the toolbar, one in Actions view and one in the editor toolbar)
     • Move the "Add content" action to the Sidebar toolbar, use file-add icon
     • Move "Optimize slug" to view-action of the Metadata View, use rocket icon
     • Move the "open preview" to the Editor's Actions, use open-preview icon
     • Move the "start server" to the Sidebar toolbar
     • Move the "enable writing settings" and "toggle center mode", to the Editor's Actions
     • Move "Create template", "Reveal file/project...", "Open documentation", "Settings overview" and "Report an issue" to the "..." of the Sidebar toolbar
   • Reorganize the sidebar (top to bottom)
     1. "Recently Opened" should be the first or last view in the list (it's similar to "opened editors" in Explorer so it's a good spot for that section).
     2. Second the "Metadata" section, because it's the first thing of the post, the frontmatter, which intuitively should be the first thing on the sidebar
     3. Third, SEO
        • combine it's "Recommendations and "More details" into one table called "Insights" (concept graphic below)
        • move "Keywords" right below the "Insights" because it can occupy a lot of space!
        • Think about rearranging the keywords table from 2 columns with very tall rows into 6 columns with short rows. Each column for check would have an icon in the header with a hover tooltip (icons — "Title": quote, "Description": note, "Slug": link, "Content: book, "Used in Headings": label 'H1' or tag, "Keyword usage": percent sign, pulse or symbol-keyword)
          
     4. finally the "Metadata" view
     • Add a "Fix frontmatter from content type" action which (after confirmation) overrides frontmatter fields (removes extra, adds missing) based on the content-type.
     • Use a dropdown for selecting the content type, similar to the one used in the Debugger tool window for choosing configuration.
     • Move "Create content type (from this file)" and "Add missing fields to content type" to the ... view actions. They should have confirmation dialogs informing about overwriting global config for content-type.

Additional context
A simple rendition of what I have in mind, generally.

[estruyf]

I've started implementing some of the suggestions. The first thing I worked on is the SEO status section.

[estruyf]

Don't show the name of the file in the primary sidebar of the extension. That's what the tab pane is for. Without the filename there will be more space for actions

This has been added for when working with previews. Originally, it wasn't added, but when you open a preview in VS Code, you go to a new view. When working with multiple articles, you might lose the context. So based on feedback, the filename has been added to the panel.

Moving actions to editor toolbar or to the Sidebar toolbar

The problem is that only a couple of actions can be shown. The others will be hidden within the menu. As much as I like the idea, having these actions in the panel is still easier as they will always be at the same location, so the user doesn't have to open an additional menu to find other actions.

[T3sT3ro]

The new keywords view looks very nice! Looking at it I had an idea for going even a step further:

deduplicate the keyword table and the keyword "badges" that are below (same information present in 2 places) into badges directly in the table like so (mind the fonts/ alignment/spacing, it's a quick mock made in excalidraw):

The problem is that only a couple of actions can be shown. The others will be hidden within the menu. As much as I like the idea, having these actions in the panel is still easier as they will always be at the same location, so the user doesn't have to open an additional menu to find other actions.

I think it's worthwhile to consider:

• the context of the action — is it global (independent of a post) or contextual? Some actions, such as "open dashboard", "start server" and "create content" are universal, global, independent of the current post. Placing them in in the panel makes it seem as if they belong contextually to the current post. They logically don't belong in the same place as single post's "optimize slug" or "open preview".
• the importance and usage frequency of an action. For example "Open dashboard" (needlessly present in both places: once in the sidebar toolbar and once in the actions fold). I think there are other more important and frequently used items. The breakdown:
  1. "Open dashboard": already present in toolbar header. No need for that action at all
  2. "Optimize slug": I can see this action used only when the title changes. This seems infrequent. Can be safely put in a menu, 1 more click doesn't make a difference here.
  3. "Open preview": personally I don't use that action when I'm running my localhost server. I either preview the content using "Open preview to the side" in the editor toolbar (image below) or view it directly on my live rendered page
     
  4. "Start server": I personally don't use that action. I use VSCode launch configurations instead. Thus I find this action to be redundant, given that VSCode already has an established mechanism for launching things and running tasks. When it comes to the frequency of usage, this is something you hopefully run once for an editing session. For an action you run only one time when you launch VSCode it occupies too important spot in the sidebar.
  5. "Create content": this action is universal, and should be immediately accessible. I am confused why it's both in the post's actions and in the dashboard. I also think that having to scroll to that action is hinders UX.
• familiarity: how well do elements integrate with existing UI? Some actions, like mentioned above, duplicate existing functionality of VS Code. Some are unlike other extensions (e.g. one row button for action).

Ultimately, I think the actions in their current form are either duplicating the built-in functionality of VSCode or don't make much logical sense

The issue with actions is that they are also in a pretty weird place. They are placed below "SEO Status" fold (which can grow in size depending on the keywords), and they push the "Metadata" (which imo is the most important bit in the side panel) far below. When it comes to the importance, I find

It is worth considering that currently not all actions follow the logical flow of the UI: when they are in the sidebar's fold, they seem to be related to "this article". But in reality, "open dashboard" and "start server" are global actions unrelated to the current file.

And the final thing are "other actions" that I have to scroll all the way down to access. They can be even pretty hard to discover.

[estruyf]

Great idea for the keywords. I have implemented the change:

[estruyf]

I had some other feedback:

Much better, but I would go a step further.
If something is OK, hide it and show only things that need attention or are broken. Also, a link at the bottom "show completed". And when everything is done a note "Everything is amazing" + the link to show it.
Less alert fatigue IMO.

Created a new mockup, what do you think?

---

---

[T3sT3ro]

(quick info — I passed the following message through GPT to help me in wording/redaction/convey my message more clearly. I am not yet that proficient in english to write good feedback without bloating my message needlessly >-<)

Good point about alert fatigue. However, I have some concerns about the proposed solution and the updated mocks:

1. UI Space Usage:
   The new mock design appears to occupy significantly more space, requiring users to scroll to access important metrics like post length. The current compact layout keeps everything visible and organized in one place, which aligns well with the tab's purpose—it’s called "Insights," not "Problems," as it showcases post stats.

2. Message Clarity:
   Some messages in the mock are ambiguous. For example:
   “Internal links: 0, Add internal links to improve SEO”
   Is this a warning, a suggestion, or just informational? It’s unclear whether this is a critical issue or a recommendation for optimization.

3. Compactness & Accessibility:
   I appreciate the compactness of the current design, especially with the most important metrics at the top. They’re concise, accessible, and avoid unnecessary scrolling without sacrificing value.

4. UI/Content Jumping:
   Items moving dynamically between "Items needing attention" and "Completed items" could cause frustrating layout jumps, especially while editing. Constant changes in the sidebar could disrupt focus, make reading harder, and force users to manage two views (resolved and pending), complicating the workflow.

5. Keyword Splits:
   Separating keywords into “attention needed” and “resolved” introduces unnecessary complexity. Users would need to scroll through multiple sections to manage keywords, which could lead to confusion. For instance:

   • Defining keywords like "apple" and "banana" could result in "banana" disappearing into a collapsed "completed" section immediately, making it seem like it was lost.
   • This issue would require additional UI elements to ensure keywords remain easily manageable in one place.

6. Single Location for Insights:
   The current "Insights" tab consolidates resolved and pending issues effectively. Splitting it into separate sections could hinder usability by increasing the need to switch views or scroll.

7. Naming Consistency:
   The mock lacks clarity in naming and grouping. For example:

   • “Title: 51/60” vs. “apps: 1.17%” — It’s unclear what “apps” represents without additional labels or grouping. Clear categorization would make the interface more intuitive.

8. Always-Visible Metrics:
   Some metrics, like title length and description length, are valuable as always-visible elements that dynamically update during writing. Similarly, showing keyword density prominently is beneficial and aligns with the tab's purpose.

---

Regarding error fatigue:
I agree it’s an issue worth resolving. While a table view for each keyword might be overkill, hiding resolved issues could help declutter the UI. Here are two potential solutions:

1. Folded Sections per Keyword (not ideal):

   • This would show issues per keyword in collapsible sections. However, it could introduce minor layout jumps and increase visual clutter.

2. Warning Badges with Tooltips (preferred):

   • Place badges next to keywords, indicating the number and types of issues. Tooltips could provide additional context when hovered over.
   • This approach minimizes space usage, avoids layout jumps, and keeps information accessible at a glance. I’ll work on a mockup to illustrate this idea.

As a final tangent: consider using the VS Code's built in "Problems" view and problem matcher to report and resolve the issues.

[T3sT3ro]

And here is a mock. The details would need some working on. For example we could show a green tick badge when there are no problems to indicate "resolved issues" as in the feedback from the other guy. Or even better, instead of "problems" it would be "steps to do" and shown as 5/5 when everything is OK (hover over shows a list of the current 5 items) and if some errors are present, then it's presented as e.g. 3/5 and a warning icon. You could also merge the keyword frequency with the issues and make 6/6 where one of them is "keyword frequency too high/low" (because on the following mock there would be two icons - for issues and keywords - next to each other which may be still too much)

[T3sT3ro]

Improved mock with "checks" for each keyword (colored frequency label to reconsider, white may look better). Also the badge with problems could be done in negative for better look, but is harder to draw for me in the mock. The tooltip when hovering over the "checks" badge could show a list with icons and items for each one, with green tick for completed item and yellow warning icon for item needing attention.

[estruyf]

Last mockup looks great 😊 and your thoughts about how the keyword section should behave make total sense.

I'm not sure yet about the insights section, although it already looks way cleaner and structured.

[estruyf]

Changed it, in the upcoming beta it will look as follows:

[T3sT3ro]

Looking lovely!!! For some minor adjustments, center the "checks" column header and center the badges in that column, both horizontally and vertically within the rows. You can see if using "Frequency" instead of "Freq." fits, there seems to be enough space in the header if the icons next to the frequency are present. I used shortened "Freq." in the mock when I removed the icons.

[estruyf]

I had already improved it a bit, also implemented the feedback.

[T3sT3ro]

Do labels and the checks badge hit the contrast ratio under dark theme? If not, consider doing white text on green/yellow background for the badges (and for frequency).

What do you think about centering "Checks" and "Frequency" column haders?

When it comes to frequency numbers it could be added to the checks with "Keyword frequency between x-y".

On a second thought, depending only on the color of the label may not be a good idea from the accessibility standpoint, so the previous icon + black label for frequency could have been actually better.

As for the badges (based on this source) maybe consider using some slight, dimmed colored background. Alternatively dark solid background and light text to hit the contrast ratio.

And also now thanks to the tooltip the check names can be made more descriptive, like "present in the title" instead of some "title". And icons placed before the text to align them vertically and tidy it up a bit.

[estruyf]

Do labels and the checks badge hit the contrast ratio under dark theme? If not, consider doing white text on green/yellow background for the badges (and for frequency).

I've added a background color based on theme colors.

What do you think about centering "Checks" and "Frequency" column headers?

It is now using the default VS Code table styling

When it comes to frequency numbers it could be added to the checks with "Keyword frequency between x-y".

Checks IMO, are easier to understand than it is right now. The frequency doesn't take up too much space.

And also now thanks to the tooltip the check names can be made more descriptive, like "present in the title" instead of some "title". And icons placed before the text to align them vertically and tidy it up a bit.

I've added a title in the tooltip

[estruyf]

While looking at it, centered checks and frequency titles just look better.

[T3sT3ro]

I noticed the keywords text and X button aren't aligned vertically -> tested locally, they look fine 👍

[estruyf]

I think its fine, as the text is in lowercase. Here you can see it in uppercase:

[T3sT3ro]

I'm testing the current beta branch and it's looking good. Things I noticed for now (aside from some small bugs like resizable observer errors and frequency not updating):

• Frequency is colored in yellow, but there is no info if it's too high or too low I'm blind, it's below the list, but this may be slightly confusing. To solve this, maybe an up arrow icon (and tooltip) to show when the frequency is too high, and down arrow with tooltip to show when it's too low? Then get rid of the * symbol and the tip below the table.
• the icons seem to be loosing detail, seem to be too small. Maybe try using 1.2 or 1.5 em scale for them relative to the badge text. The exact number would be handpicked. On the second look though I see the "project warnings" on the bottom status bar (official VSCode UI element) also has similar issue, although their icon seems to be just slightly bigger giving more detail.
• colors seem a bit dull on my dark theme for some reason (Default Dark Modern theme)
• for long keywords, the keywords make the table scroll horizontally.
• keywords and action buttons look too similar. References from other sites show badges are usually using fonts with higher weight, maybe using strong/emphasis for that. References i added below are show it well.

Here is how it looks:

For long keywords:

I didn't see any centering issues when I tested locally, keywords indeed look fine.

For a small adjustments I would use a 2:1 padding scale for X:Y padding in the padding for keyword and the checks badge, also making them slightly shorter in height and but wider. I checked out the beta branch locally to see for myself how it looks like, because I don't want to be only talking without doing something myself :)

Also here is a reference for badges from some other product I found online which imo looks good (notice the heavier font weight, simplicity without borders and how they are wider than taller):

Does VSCode has some design system? If not, then github's Primer is a good foundation that I think is very similar and fitting VSCode, so some elements could be copied from there.

[T3sT3ro]

If you are interested here is the patch of changes I did to perform small tweaks (the patch would need revision, it makes some changes in place):

Patch on top of 42fe1c2

diff --git a/src/dashboardWebView/components/css-vscode-variables.css b/src/dashboardWebView/components/css-vscode-variables.css
index 6d5e566a..27ccb164 100644
--- a/src/dashboardWebView/components/css-vscode-variables.css
+++ b/src/dashboardWebView/components/css-vscode-variables.css
@@ -338,6 +338,7 @@
   --vscode-statusBarItem-errorBackground: #611708;
   --vscode-statusBarItem-errorForeground: #ffffff;
   --vscode-statusBarItem-warningBackground: #725102;
+  --vscode-statusBarItem-warningText: #cdab11;
   --vscode-statusBarItem-warningForeground: #ffffff;
   --vscode-activityBar-background: #ddd6c1;
   --vscode-activityBar-foreground: #584c27;
diff --git a/src/localization/localization.enum.ts b/src/localization/localization.enum.ts
index f4cac251..4173d25b 100644
--- a/src/localization/localization.enum.ts
+++ b/src/localization/localization.enum.ts
@@ -1613,7 +1613,7 @@ export enum LocalizationKey {
    */
   panelSeoKeywordsDensity = 'panel.seoKeywords.density',
   /**
-   * Used in heading(s)
+   * Heading(s)
    */
   panelSeoKeywordInfoValidInfoLabel = 'panel.seoKeywordInfo.validInfo.label',
   /**
diff --git a/src/panelWebView/components/SeoKeywordInfo.tsx b/src/panelWebView/components/SeoKeywordInfo.tsx
index 871a5e01..d0e65fa7 100644
--- a/src/panelWebView/components/SeoKeywordInfo.tsx
+++ b/src/panelWebView/components/SeoKeywordInfo.tsx
@@ -42,11 +42,11 @@ const SeoKeywordInfo: React.FunctionComponent<ISeoKeywordInfoProps> = ({
     const densityTitle = `${density.toFixed(2)}* %`;
 
     if (density < 0.75) {
-      return <span className='text-[12px] text-[var(--vscode-statusBarItem-warningBackground)]'>{densityTitle}</span>;
+      return <span className='text-[12px] text-[#cdab11]'>{densityTitle}</span>;
     } else if (density >= 0.75 && density < 1.5) {
       return <span className='text-[12px] text-[var(--vscode-charts-green)]'>{densityTitle}</span>;
     } else {
-      return <span className='text-[12px] text-[var(--vscode-statusBarItem-warningBackground)]'>{densityTitle}</span>;
+      return <span className='text-[12px] text-[#cdab11]'>{densityTitle}</span>;
     }
   };
 
@@ -116,7 +116,10 @@ const SeoKeywordInfo: React.FunctionComponent<ISeoKeywordInfoProps> = ({
 
     return (
       <div 
-        className={`inline-flex py-1 px-[4px] rounded-[3px] justify-center items-center text-[12px] leading-[16px] border border-solid ${isValid ? "text-[--vscode-charts-green] border-[--vscode-charts-green] bg-[--frontmatter-success-background]" : "text-[var(--vscode-statusBarItem-warningBackground)] border-[var(--vscode-statusBarItem-warningBackground)] bg-[--frontmatter-warning-background]"}`}
+        className={`inline-flex py-1 px-2 rounded-[3px] justify-center items-center text-[12px] leading-[16px] border border-solid 
+          ${isValid 
+            ? "text-[--vscode-charts-green] border-[--vscode-charts-green] bg-[--frontmatter-success-background]" 
+            : "text-[#cdab11] border-[var(--vscode-statusBarItem-warningText)] bg-[--frontmatter-warning-background]"}`}
         data-tooltip-id={`tooltip-checks-${keyword}`}
       >
         <ValidInfo isValid={isValid} />
@@ -137,7 +140,7 @@ const SeoKeywordInfo: React.FunctionComponent<ISeoKeywordInfoProps> = ({
         <div className='flex h-full items-center'>
           <Tag
             value={keyword}
-            className={`!w-full !justify-between !mx-0 !my-1 !px-2 !py-1`}
+            className={`!w-full !justify-between !mx-0 !my-1 !px-2 !py-0.5`}
             onRemove={onRemove}
             onCreate={() => void 0}
             title={localize(LocalizationKey.panelTagsTagWarning, keyword)}
diff --git a/src/panelWebView/components/ValidInfo.tsx b/src/panelWebView/components/ValidInfo.tsx
index 8120aada..189ee025 100644
--- a/src/panelWebView/components/ValidInfo.tsx
+++ b/src/panelWebView/components/ValidInfo.tsx
@@ -15,11 +15,11 @@ const ValidInfo: React.FunctionComponent<IValidInfoProps> = ({
   return (
     <div className='inline-flex items-center h-full'>
       {isValid ? (
-        <CheckIcon className={`h-4 w-4 text-[var(--vscode-charts-green)] mr-2`} />
+        <CheckIcon className={`h-5 w-5 text-[var(--vscode-charts-green)] mr-2`} />
       ) : (
-        <ExclamationTriangleIcon className={`h-4 w-4 text-[var(--vscode-statusBarItem-warningBackground)] mr-2`} />
+        <ExclamationTriangleIcon className={`h-5 w-5 text-[#cdab11] mr-2`} />
       )}
-      {label && <span className={className || ""}>{label}</span>}
+      {label && <span className={className || ""}><b>{label}</b></span>}
     </div>
   );
 };
diff --git a/src/panelWebView/styles.css b/src/panelWebView/styles.css
index 355be5f5..b0e76cf9 100644
--- a/src/panelWebView/styles.css
+++ b/src/panelWebView/styles.css
@@ -897,6 +897,10 @@ vscode-divider {
 
 .tag .tag__delete {
   margin-left: 0.25rem;
+
+  & svg {
+    stroke-width: 3;
+  }
 }
 
 .tag .tag__delete:hover {
@@ -911,7 +915,8 @@ vscode-divider {
 
 .tag .tag__value {
   flex-grow: 1;
-  white-space: nowrap;
+  white-space: pre-wrap;
+  font-weight: 600;
 }
 
 /* Slug field */

And the changes look like that:

[estruyf]

@T3sT3ro would you be able to create a PR for this? That way you become part of the contributors list.

[T3sT3ro]

Yeah, I could try later today 👍
It must wait a short while for my empty time slot >-<

[estruyf]

I was reviewing your code changes. You cannot add anything to the css-vscode-variables.css file, this is just a reference file with all the VS Code CSS variables the webview receives. So the --vscode-statusBarItem-warningText variable you introduced won't exist.

We need to work with the variables VS Code provides us.

[T3sT3ro]

Oh, good, I also didn't get why it wasn't working in there. Is this list of classes up to date? What's it's source of truth? I tried looking for some "VSCode design system" but sadly there is none (and their webui project is closing down)

[estruyf]

I know, I've been discussing this in the community. We started a new community effort to recreate the components, as the fast foundation dependency was deprecated/removed. During the development, some members found another library: https://vscode-elements.github.io/

I always wanted to fix issues with the web components and event handling in React. There were some workarounds that I had implemented in the past, so I started another project. Which is a component library for React based on the original VS Code toolkit: https://www.npmjs.com/package/vscrui

Is this list of classes up to date? What's it's source of truth?

The variables can be retrieved from the vscode://schemas/color-theme schema, which you can get when creating a theme, but the easiest option is to open the developer tools and check the variables set on the HTML element of your webview.

[T3sT3ro]

I have submitted the required adjustments, IMO they look good :)

Now going back to the original issue and the issue I have with actions:

Moving actions to editor toolbar or to the Sidebar toolbar

The problem is that only a couple of actions can be shown. The others will be hidden within the menu. As much as I like the idea, having these actions in the panel is still easier as they will always be at the same location, so the user doesn't have to open an additional menu to find other actions.

Their current design goes directly against the official VS Code UX guidelines:

Dont's:
(...)

• Use tree items as single action items (for example, firing a Command on click)

IMO it should be done like it's done in other extensions — using panel toolbar and context menus, or with automatically registered tasks.

[estruyf]

Thanks, @T3sT3ro; I've merged your changes, and they will be available in the latest beta version.

[estruyf]

There are still items that need to be picked up in the future. Let us split these up into new issues so they are manageable and easier to track.