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.