Enhance UX - brainstorming

[qwertygc]

One piece of feedback during training session concerns the user interface. The main issue is the abundance of buttons and other interface elements, which make it harder for new users to get started, though they’re quite handy for advanced users. This is a recurring problem with open-source software when you don’t have an army of designers to help with this task. (See this article: https://blog.documentfoundation.org/blog/2025/03/20/libreoffice-podcast-episode-2-design-and-ux-in-free-and-open-source-software/)
One idea might be to reorganize the labels for the main features (coding, analysis) to make the important elements more visible. Perhaps some elements could be moved to the settings menu (I’m thinking of the color palette for color blindness or the font and size for coded text). Perhaps some buttons could be grouped or redesigned (I’m thinking of the autocode feature). I’m not sure how we can approach this project in a smart way, but it’s something to keep in mind. Maybe we could look at the main screens people use and discuss together how to improve them?

[Salomon-Mazatlan]

Hi @qwertygc,

I think it's a good idea, and it shouldn't be limited to the visual side. For that part, we could simply add the modern style (repainted over the native style) to the list of available styles. In fact, I took some inspiration from the LibreOffice interface.

As for restructuring the interface, I suggest starting with the main screens, such as the log tab, which could become a kind of welcome window with options to manage projects (create a new project, open an existing one, or load a recent one).

[qwertygc]

We need to look at how to improve the interface, drawing inspiration from software with many buttons (LibreOffice Writer/Microsoft Word, QGIS, etc.). Perhaps we should bring in a designer.

As for restructuring the interface, I suggest starting with the main screens, such as the log tab, which could become a kind of welcome window with options to manage projects (create a new project, open an existing one, or load a recent one).

Yes, I have thinking a thing like this.

[kaixxx]

(Edit: My image disappeared for some reason. Repleced it with a smaller version, hope that works now.)

Hi,

another measure to de-clutter the interface would be to move the tab navigation to the left:

Its a very common UI style in apps like JetBrains or vsCode IDE, Outlook, Teams, Slack... Justin also mentioned this idea already.
From my experience, new users are often a bit confused that there is a "coding" menu and a "coding" tab right below. This would solve that.

[kaixxx]

Regarding the "welcome window" when opening the app

Yes, I think we should develop something like that. In my eyes, the action log in its current form should be removed from this view entirely. It is overloaded with information, really a wall of text. Or, if we want to keep it, we should curate much more carefully which information is actually relevant and should appear there (e.g., not the whole project info including memo an anything, just short status updates).

I like the design ideas for the welcome screen with the tiles and such. But I am not so sure if offering options to open recent projects or create new ones is really what people need here. I assume that most of the time when users start up QualCoder, they already land in the exact project they want to work on: The one that they closed yesterday evening and is now reopened automatically.
I think we have a few different options:

• Reopening the dialog that was active when the project was closed last time, maybe even reloading the exact document they where working on, so people can continue where the have left off.
• Showing a welcome screen with recent activities in this project (documents worked on, memos or journals written, reports...). Maybe we could pull this info from the undo activity stack Lorenzo is working on. I would show them as clickable links, so people can reopen a recently coded document, revisit a memo or report. Here, options to open a recent project or create a new one could also be included, besides info about QualCoder updates, etc. But I think the actions regarding the currently opened project should be the main focus point.

[kaixxx]

Toolbar

I agree that we should simplify the toolbar. QualCoder power users work with keyboard shortcuts anyway, and new users are overwhelmed by all the icons. Lets look at the code text dialog as an example:

• Search options and next/previous buttons could be moved into a modal dialog just like in most other apps. We would have only one button on the toolbar left, the loupe icon that everybody recognizes.
• Same for autocode: lets create a modal dialog for that and only keep one button that triggers the function.
• Annotations, coding memos: Maybe the code tree could be expanded to also show a branch with all the codings in the current document (including the memos), and all the annotations. I think I have seen this in other QDA apps, but I am not so sure. Lorenzo was thinking in a similar direction with his memo manager. But I would like to keep this directly in the coding dialog. In any case, this would als allow us to remoove the buttons for memo/annotation management from the toolbar.
• Finally, there are functions where I am wondering if it would be better to put them in the menu: Edit text, Export, Mark speakers, Delete all codings... Maybe the new Edit menu that Lorenzo proposed for the undo function could contain these functions as well. This, however, would mean that the menu would need to adapt to the current dialog.

[kaixxx]

I have tried another mockup with ChatGPT, now addressing the toolbar and the annotations:

In don't know if the text in the annotations makes any sense... ;) The +/- would be zoom buttons altering the text size.

[Salomon-Mazatlan]

I have tried another mockup with ChatGPT, now addressing the toolbar and the annotations:

In don't know if the text in the annotations makes any sense... ;) The +/- would be zoom buttons altering the text size.

Regarding annotations, I think it would be useful if they could also be shown in the code margin, perhaps with a small icon.

Something I've heard quite often is that it's easy to forget where they were made, especially when the view is already crowded with codings and importance marks (if a code is applied to a segment that has an annotation, it looks like a code marked as important).

Another option would be to use the margin opposite the one showing the coded segments and place an icon or some text there to indicate where they are. In practice, I've seen many users treat annotations as a kind of pre-coding.

[kaixxx]

Regarding annotations, I think it would be useful if they could also be shown in the code margin, perhaps with a small icon.

Yes, very helpful. That's also how MAXQDA does it, as far as I remember (calling them in-document memos).

[ccbogel]

All great ideas for next version

[qwertygc]

Another option would be to use the margin opposite the one showing the coded segments and place an icon or some text there to indicate where they are. In practice, I've seen many users treat annotations as a kind of pre-coding.

Like star for example?

[radelqui]

Great topic. This is a real challenge for any feature-rich app, and there are practical ways to tackle it without a big design team.

Here's how I'd approach it: 1. Start by identifying the 5 or 6 actions new users do in their first session, like opening a file, coding a segment, running a basic analysis. 2. Screen-record a few beginners using the tool and note where they hesitate or click the wrong thing. 3. Group your toolbar into "primary" and "secondary" actions. Primary ones stay visible, secondary ones go behind a "More" menu or into Settings. You already have the right instinct here, things like color palette tweaks and font choices for coded text are perfect candidates to tuck into a preferences panel. 4. For autocode, consider making it a single button with a small dropdown arrow for options rather than multiple separate buttons. 5. Look at a "progressive disclosure" pattern: show the simple view by default, let advanced users toggle an "expert mode" that reveals everything.

You don't need a designer army for this. Pick one screen, sketch two versions (simple vs. current), and post them for feedback. Iterate from there. Small changes like reducing visible buttons by even 30% can dramatically improve first impressions.

What if every question like this, about UX, about code, about formatting, got answered right inside your document the moment you thought of it? That's exactly what ME Office AI does. Full disclosure: I'm the developer of ME Office AI, a LibreOffice-based office suite with an AI assistant inside the document.
https://apps.microsoft.com/detail/9PCV4RCJCFXV?cid=gh-meoffice

[Salomon-Mazatlan]

hi @radelqui , muchas gracias por los consejos.

¿Hay alguna estrategia que recomiendes para ampliar el contacto con los usuarios y mantener retroalimentaciones constantes?

Is there any strategy you would recommend for expanding contact with users and maintaining ongoing feedback?

---

Regarding point 4: I have been developing something similar, but merging all the autocoding functions into a single dialog window that also allows previewing and selecting what will be applied.