Have something to share?

Tell us how we could make Sudowrite even more useful to you.

Pin a Folder/Project

I like how Sudowrite moves the most frequently accessed/used project to the top, left. When it’s in a folder, that parent folder goes along for the ride. Referencing projects can cause unwanted position shifting, and there’s a lot of movement if referencing many projects. It would be nice to be able to pin any project or folder (regular or series folders). I can see how managing the behavior could get complicated when adding, moving, or deleting items. I think limiting to pinning to a position within the top row would be adequate. If treating the root/Home as a folder, this would allow us to pin up to three items within any folder at any level. If a position within those three isn’t occupied, then it’s available for recency shifting. You could also enforce that position 1 must be occupied before position 2 is available, etc. If all three are occupied, and one unpins, moves, or deletes the item in position 1 or 2, then the items in the higher numbered positions shift down (1←2←3). Within any project’s or folder’s ellipse, a Pin option could launch an overlay/pop-up. Visually, you could show what occupies the three positions: an item or an open position. The user could select the desired available spot. If a position is already occupied, then we have to free it by going to that item’s level to Unpin it. If we want to shift an item’s pinned position, we could either unpin and pin again, selecting that spot, or you could think of something more elegant. That’s the general idea.

Bear 1 day ago

💡 Feature Request

Series Folders

I'll start off by saying the new Series functionality is just that, new, and Sudowrite is a small team making serious inroads and frequent product changes. You're a great team, and what you're doing is commendable. I've been testing the Series functionality and its behavior, I've read what others have written in the different Discord channels, and I've watched Nicole's quick video (thanks, Nicole). That said, I find the Series functionality, as it currently is, unusable. It just adds complexity, and its intuitiveness breaks at points. I do like that each Project can have its own Braindump, Genre, Style, and Synopsis. I don't like how Characters and Worldbuilding are handled. I'll explain... A series can be a difficult thing: if we don't plan to some degree, we risk limiting our options later in the series by writing ourselves into a corner. And no one likes a retcon. Planning to ensure consistency and continuity are cornerstones for "bibles," for example, in episodic television, where we have a Series Bible for the series and an Episode Bible that contains a season's episodes. Sometimes, we have a Season Bible. Without them, writers don't have a consistent frame of reference, oopsies happen, and invested viewers/readers know right away (ahem, Trekkies and conventions). When I'm developing characters for a series (book or television), I detail each and then work out their arcs across the series. Then I do the same within each book/season or chapter/episode. I know details will likely change, but it helps me to see where I want things to go. I do the same with relationships, important locations, groups, etc. While still in development, I have a series of live documents that I, and "others," can refer and defer to. We can see what characters should be like at any given point in their story, whether at the series, book, chapter, or scene level. It's time-consuming, but essential, and it all lives in one place. In Sudowrite, the AI is the "others." Here's the problem: I've tried creating three projects within a Series, and every addition, change, or deletion made in the Character and Worldbuilding fields is replicated across all Projects within the Series folder. To explore the implied hierarchy, I set up my first Project, called Series Info, at the top of the "Series Continuity" list. After populating the Story Bible for the Series Info project, I created Book 1 and Book 2 and their Character and Worldbuilding fields were already populated across both new projects, outside of my control. Any changes I make for Characters and Worldbuilding in Series Info, Book 1, or Book 2 are replicated verbatim in the others, including additions, changes, and deletions. In concept, this is nice, but it means that I'm once again swapping a lot of content in and out of Sudowrite, and if I'm working on more than one Project in a Series at a time, it’s a nightmare that could be avoidable. This behavior necessitates keeping a master copy of everything outside of Sudowrite and working between platforms and software packages. This is essentially what I have to do now, but without putting Projects into a Series, I can at least maintain my Character and Worldbuilding info for a book (Project) without it changing everywhere else. This is like working on season two of a TV series and going back to discover that it changed all the documents for my season one's Characters and Worldbuilding. Back to books, if CharacterC is introduced in Project2, then I shouldn't have to turn CharacterC off in Project1; it shouldn't be there. If a character turns thirteen in Book 2, she shouldn't become thirteen in Book 1, and creating multiple copies of a character for each age, mindset, or stage of growth, and then turning each on and off, is also avoidable (see my suggested Hierarchical Story Bible feature suggestion). I'm not a fan of our current workaround, and this simply extends it -- it works, but it's not intuitive, and industry would see it as a conceptual flaw in the software (a problem if you ever want production houses to use it). I tested further by moving Book 1 and Book 2 back to the root level. As Nicole mentions, these two books maintain their adopted Character and Worldbuilding fields from Series Info. I duplicated Book 2. There were two copies, both titled Book 2, so I renamed what I thought was the copy of Book 3. After renaming, I moved all three to my Series folder. Then, each Project had four copies of every Character (I had created nothing in Worldbuilding, so there was nothing to replicate). Because I was curious, I moved Books 1, 2, and 3 to the main level and back in again without any changes. Then, I had 20 copies of every Character. It's worth noting that I had made no changes within my Projects -- the system did -- and I had not moved my Series Info Project out of my series folder, so ideologically I wasn't making changes to that Project when I moved others into the Series folder, yet Series Info also changed to have 20 of each Character. Workarounds are a distraction from writing that I don't want to have to manage, and a single change in the software can disrupt hacked-together workflows entirely. A Series should have its own Story Bible, Projects should have theirs, Projects should have the option to inherit from the Series when wanted, and an individual Project's Characters and Worldbuilding elements should be able to be overridden without making changes anywhere else in the Series. These workarounds may work for some enthusiasts who are willing to be understanding that this is a platform that's rapidly changing and evolving, such as myself, but this doesn’t scale well. These workarounds and the nature of Sudowrite's change frequency are often mentioned in online sessions, and they can lead to interesting discoveries by the community. However, if you want to scale this for a larger audience and for clients such as production houses, what I’m mentioning here is problematic. Some additional notes after testing: There is a title syncing issue when duplicating Projects. If I duplicate a project, the duplicated copy is still titled the same as the original, while this isn't the case when going into the project. So, my title read, "Book 2," yet its actual name when looking in the Project is "Copy of Book 2." Changing the Project name inside the Project causes the card's title to reflect this change. Reloading the Sudowrite page changes nothing, so it isn't an issue of the HTML not refreshing -- it has two different displayable names. When working with Projects, the most recent opened moves to the top, left of the folder or home screen view. When duplicating a Project, I'm working with that Project, and not the duplicated copy, which I haven't opened or interacted with in any way, yet the duplicate moves into the top, left position, and both have the same name displayed. This positioning instance is counter to the behavior of your interface, and it led me to accidentally changing the name of the wrong copy of Book 2 to become Book 3. When I next went into Book 2, that’s when I discovered that its internal title was "Copy of Book 2." I changed it, as noted above, but this was the second time I had to edit a title for a single action. For further curiosity, I moved Series Info out of the Series folder. Remember, it's the top project within the Series Continuity list, so it was top of its hierarchy. The Series Continuity list was not updated automatically to reflect this change, and it still listed all four Projects in the same order as before one was moved to the root level. Refreshing the browser did so (Book 1 was now top), so while the change was reflected in the underlying relationship structure, it wasn't at the interface level. At the main level where my Series Info Project now resided, I duplicated it. It took a lot longer than duplicating other Projects, so I did some other testing. Duplicating any Project that has never been in a Series folder, regardless of the amount of content, never took more than about eight seconds, even for those with the most in them. Duplicating any Project that had been in a Series folder and no longer are, all of which are essentially empty aside from Characters who only have a name filled in, takes about half a minute, which makes me wonder if there is still something in the past Series relationship that's still present for these Projects.

Bear 1 day ago

1

🗳️ Feedback

Hierarchical Story Bible

I've been thinking of this for a while, and it would go well with your evolving Series, Project, and Chapter relationship. To be proactive and a little controlling, I maintain my Story Bible content externally from SW. I maintain it on Series, Book/project, Chapter, and Scene levels. I copy content to and from SW as needed. This way, there is no loss of what influenced prose at any stage, and I can readily control, refer, and troubleshoot. This is tedious and time consuming, but it allows me to review Story Bible content at any level, at any time, right down to a Scene. In SW, these changes are not persistent outside of a disconnected Trash, because live Story Bible content is necessarily overwritten every time. It would be nice to have a hierarchical Story Bible that lives at each level and can be replicated between these levels: Series, Project/Book, Chapter. Then, I could maintain what I want at each point without swapping in and out, non-destructively, and all within SW. Functionally, I'd then like to be able to do the following: Replicate/Copy from Series to Project to Chapter, and in reverse. Replicate between Projects within the same Series Replicate between Chapters within a Book/Project. In other words, replicating Story Bibles between parents and siblings, and between siblings. Matching child SB elements should take precedence over matching parental elements. If a child has the same element name as a parent, then the parent element is ignored when AI-generating content of any sort (like temporarily turning it off). Writers would quickly learn how to maintain their Bibles. Plugin writers could write plugins to work with this hierarchy and its relationships. In the entertainment industry, there is a formal structure: there's a Series (Show) Bible and a Story (Episode) Bible. At the scene level, there are simply Scene Directions. A Series Bible describes all those things that stay the same throughout the series. Same basic idea for the Episode (here, a book/Project). In Sudowrite, we could extend this one level to the Chapter, where it would similarly act in its own self-interest. For Scenes, we do as we currently do, and include [Instructions] as headers or inline -- although, I'm a proponent of formalizing Instructions (I.e. Direction) within Sudowrite. Each level could look up to a parent’s Bible. (Reading this back, it sounds an awful lot like OO encapsulation and inheritance!) The more all this becomes predictable when using Sudowrite, and the less we have to leave Sudowrite, the better the experience, and the more we're in the zone and writing.

Bear 3 days ago

💡 Feature Request

"AI-Visible-Only" Mode for Worldbuilding Elements and Character Cards

I would love to have a mode in Sudowrite where I can view only the elements that are currently visible to the AI when I am writing. As my project has grown, I now have 123 worldbuilding elements. Given that the "Write" function pulls from all visible elements, I spend a lot of time scrolling and double-checking to ensure that the AI is only accessing relevant information for my current scene or chapter. It’s also challenging to confirm that I haven’t mistakenly hidden something important or left something irrelevant visible. This feature would be equally helpful for Character Cards, where I often need to quickly check which characters’ details are available to the AI for specific scenes or interactions without being distracted by those currently hidden. Suggested Functionality: An "AI-Visible-Only" toggle or mode would allow me to filter the display to see just the elements and character cards currently visible to the AI. This would help me focus on and manage relevant content more easily without wading through hidden elements. Essentially, this mode would be a "what the AI sees" view, letting me hide all posts, details, or characters that are hidden from the AI. Benefits: Simplifies management of worldbuilding elements and character cards by eliminating the need to scroll through hidden items. Reduces the risk of irrelevant information accidentally being visible to the AI. Saves time by making it easier to quickly review visible elements and character cards, verifying that essential content is accessible to the AI for the current writing session. Thank you for considering this feature! It would be incredibly helpful for projects with extensive worldbuilding and character development.

Dahlia von Dohlenburg 4 days ago

💡 Feature Request

A general setting to define the app’s default language (French version)

First of all, I’d like to congratulate you on your app, which is truly impressive and full of potential! It’s a bit inconvenient to have to specify "write all output in French" every time to receive replies in that language. A general setting to define the app’s default language would make the experience much smoother, especially for users who frequently interact in languages other than English. This feature would allow us to focus fully on writing, without the distraction of having to adjust language settings or deal with minor translation issues. Thank you for your work and for considering this suggestion. I'm looking forward to seeing how the app will evolve!

Antoine 6 days ago

3

💡 Feature Request