General UI discussion

[kriptolix]

I would like to discuss some UI aspects and suggest changes.

1. I believe it would be better to position the main menu next to the close button. The current position hides the menu when the sidebar is collapsed, and this is the type of menu that should always be accessible.

In addition, the option to access the preferences area only appears on the home screen. When the button is accessed from within a project, the preference option does not appear. I do not know if this was intentional or not, but I think the behavior and options of the button should be homogeneous throughout the use of the app.

2. I do not know if the text editor as a modal window is a good solution. I think opening the editor as a tab, just like all other content, would be better both visually and in terms of interface coherence. I also think the editor would benefit from some margin for the text on both sides, it is visually uncomfortable to use without some margin.

3. The actions for each element, which currently only have the option to delete an element, seem a bit unnecessary to me. It could be a button with just an icon, without the label, and a large button with a label. Even though other actions are planned to appear on this list, I still don't consider it a good design. For several actions, a menu button would be better.

4. For the add element button. Given the location of the button, simply using a "+" already makes its function more than clear.

5. Lastly, I'm a bit concerned about the number of clicks needed to do each thing. From the home screen, I need 8 clicks to create and start editing a scene. I know that the choice of structure is responsible for this, but it would be interesting to find ways to make this process more direct.

[cgueret]

Hey! thanks for the feedback :-)

1. Fair enough 👍🏻 That would also keep it at a consistent place with its position in the library view. We can create a ticket to implement the move
2. That's something I have been hesitant about (as you could fancy observing in the git history). That was one of my motivation to release the software in an early state: to test this approach, and the overall UI, and get some feedback. If we're both unsure a modal editor is a good idea let's try something else. I also pondered a separate window but I have a preference for single window apps so a new navigation panel is the next thing to test. Same, ticket pending...
3. Ok, I'll think about it... I also want to make such action accessible via hamburger menus in other views. That way people would not have to switch views to perform a quick action not directly related to the one they are in
4. Ok! I'll improve that as part of Improve presentation #27 :-)
5. Point taken. Not sure how to best approach that right now but 8 is indeed a lot.

[cgueret]

About the 8 clicks to get started by the way I was planning to add templates to start a new project. This way, a freshly started manuscript could already contain a few scenes ready to be edited. Doesn't fully solve the issue but could be a bit of a help

[TheShadowOfHassen]

1. I believe it would be better to position the main menu next to the close button. The current position hides the menu when the sidebar is collapsed, and this is the type of menu that should always be accessible.

I don't disagree with you, but unless I don't understand what's going on, isn't that technically what gnome does?

2. I do not know if the text editor as a modal window is a good solution. I think opening the editor as a tab, just like all other content, would be better both visually and in terms of interface coherence. I also think the editor would benefit from some margin for the text on both sides, it is visually uncomfortable to use without some margin.

I agree. I think it'd be cool if we could adjust a lot of editor settings like, margin, spacing, font, and font size-- not like a word processor where it'd be safe to the document but just so each writer can have what works best for them.

For formatting, the basic bold/ italic/ underline I think would be great, but we don't need to get too crazy. Just some people (like me) use italics for emphasis... but I digress

That said, an option for a focus editor like manuscript had would be cool.

5 Lastly, I'm a bit concerned about the number of clicks needed to do each thing. From the home screen, I need 8 clicks to create and start editing a scene. I know that the choice of structure is responsible for this, but it would be interesting to find ways to make this process more direct.

Templates would be a quick fix, however, it may be better to move some of the more crunchy planning details to optional.

When I really want to just write want to create a new file, create a "Chapter One" text and start writing, I'd separate scenes, add characters, and all that stuff once I nail down the tone of the story, and fill in the other stuff later.

Of course, sometimes I'm in the planning mood and spend a few weeks filling in the outline, characters, and world before actual writing something.

Both workflows are equally valuable, and if Scriptorium is intended to work only for one workflow way that's fine, but flexibility is also nice.

[kriptolix]

I don't disagree with you, but unless I don't understand what's going on, isn't that technically what gnome does?

Yes and no. Naltilus, the gnome file browser, has a menu in the same position as the current menu, but it has two differences: !) It has a second menu next to the close button, which made it difficult to add another menu button there. 2) The menu content is not exactly the same.

In the vast majority of gnome apps, the menu is next to the close button, such as in the terminal and the task manager.

Both workflows are equally valuable, and if Scriptorium is intended to work only for one workflow way that's fine, but flexibility is also nice.

I myself am a fan of a more minimalistic, frictionless approach, and I think it is possible to be more minimalistic while still maintaining the heavy planning aspect if the UI is designed with that in mind.

A while ago I started an app with the same philosophy as this one, but with a more minimalistic approach, but I gave up due to technical issues. After discovering this app I got excited about the idea again and started writing a new app from scratch in addition to collaborating on this one.

I will use my new app to test interface ideas, and I will suggest any that work here as well.

[cgueret]

Thanks both for the discussions. For the first point about the menu there are applications like https://github.com/johnfactotum/foliate and https://gitlab.gnome.org/World/fractal that have it in the sidebar. I think overall having it at the top right corner is what people do when there is no navigation panel in the window, otherwise considering that the main content changes the menu is moved to the side bar. So let's ponder that one a bit longer...

It seems moving the editor as a panel instead of a modal dialog is agreed. I'll test that soon, won't be a big code change. The preference dialog for the font size etc is coming at the end of the week along with buttons to set parts of the text as bold or italics :-) Some time soon there will be slightly more formatting options for things like quotes but, indeed, it's not aimed to be a full fledged word processor.

I would like for Scriptorium to be minimalist, following the HIGs, and also suitable for both plotters and pantsers but I admit it's not there yet. Especially for pantsers. By going plotting first (which is how I work) I ended up kind of imposing it in the user interface flow. That will need some rework... By the way, for inspiration I really liked https://www.atticus.io/ and in the early days I had a similar approach as them: navigation top bars to isolate different aspects. So I had one tab to plot, one to write and one to format. If people wanted to skip plotting they could jump to the writing tab directly (which was also the default). Maybe an approach to re-visit?

[cgueret]

PS: in a UI like Atticus I'd definitely keep the main menu in the top right corner all the time. In that case the main navigation would be done by the tabs on top so it makes sense to have the menu associated to them

[cgueret]

I've created #32 to plan and discuss a larger UI re-design piece

[TheShadowOfHassen]

It seems moving the editor as a panel instead of a modal dialog is agreed. I'll test that soon, won't be a big code change. The preference dialog for the font size etc is coming at the end of the week along with buttons to set parts of the text as bold or italics :-) Some time soon there will be slightly more formatting options for things like quotes but, indeed, it's not aimed to be a full fledged word processor.

I agree. Ultimately, the nitty-gritty stuff will probably want to be done in a different software.

I would like for Scriptorium to be minimalist, following the HIGs, and also suitable for both plotters and pantsers but I admit it's not there yet. Especially for pantsers. By going plotting first (which is how I work) I ended up kind of imposing it in the user interface flow. That will need some rework... By the way, for inspiration I really liked https://www.atticus.io/ and in the early days I had a similar approach as them: navigation top bars to isolate different aspects. So I had one tab to plot, one to write and one to format. If people wanted to skip plotting they could jump to the writing tab directly (which was also the default). Maybe an approach to re-visit?

Sounds like a plan.