Spark thread

Website Edits/Enhancements

Published May 30, 2026

← All sparks

Spark thread

Website Edits/Enhancements

Group

Front-End Editors Desk - Spark and Article Publishing Suite.

#1Draft

Edited May 30, 2026 · 1:20 AM

In the front-end editors desk for spark threads, make aesthetic enhancements to sparks that more clearly defines individual sparks as being published/pushed. Right now, there is no visual distinction between published and unpublished content. In particular, sparks that are longer than the editors text input field still allows/requires scrolling to view the full content. I'd like for this to be changed to where published sparks automatically adapt to the length of the published content and are displayed at that size exactly, unique and individually reacting to the actual content itself. The inverse (current scrolling/limited preview) set-up is fine, but only for unpublished content. Beyond that, there should still be a more refined difference between published and unpublished content - whether it be slightly different shades of color, or whatever the best method may be. Regarding this issue in the split screen preview feature, there should be a more subtle destinction between published and unpublished content, though in this particular case this should not be overwhelming or 'too loud' at all - as to not interfere with the whole purpose of previewing. Finally, implement a 'drafting' or more aptly, a 'auto-saving' features that can/will save content that for whatever reason is not finalized before publishing, in those cases however, that content should not actually be published and become live. it should simply just live as unfinished content in the editor.

#2Draft

Edited May 30, 2026 · 1:34 AM

In the front-end editors desk for spark threads, the 'Versions' feature meant to showcase edits/changes made to content only appears at the bottom of individual and independent sparks - it does not transition into the singular sparks contained within a spark group - this should be a feature that is applied to singular stand-alone sparks, the individual sparks making up a group, the group itself, and finally, the entire spark thread as a whole. Each of these should operate independently of one another, and be true to the changes/edits made to that specific instance itself. I like the way that it currently displays the edits/changes made upon clicking it when it is referenced, though

#3Draft

Edited May 30, 2026 · 1:44 AM

Though it updates/adds a new instance for every individual letter typed. While an interesting idea, we defiantly need to refine this a little bit. I don't want it to be so strict that it only shows edits and alterations made only once there is a fresh publish, nor do I want it to be so simple that it updates every ____ amount of times, or as it does currently, shows literally every letter. Find a nice middle ground for this - potentially being triggered anytime there are any major additions/deletions, and/or then every ___ amount of time, or something of that nature. They should also not only be present on the front end version as well, which they don't currently seem to be, but they should also be more of a pop-up/overlay and then each individual edit should be expandable to not only display the full thing, but also visually showcase the changes/edits made (for reference, think of how Github/IDE's display changes in documents between different commits. This feature also seems to cap out at 30 versions, this is fine in theory, and I do like the idea of having a established limit, but this just furthermore highlights why we need to refine the triggering mechanisms.

Group

Front-End Editors Desk - Articles and Their Publishing Suite

#4Draft

Edited May 30, 2026 · 1:57 AM

When using the top nav-bar of the front end editors desk and navigating to the articles tab, there is no direct way to begin a new article, it only shows the published ones. There is a functioning 'New' button in the card on the homepage that works just fine, but this should also be implemented when navigating to the articles page via the nav-bar, and to be quite honest, even beyond that ---- In the 'CBREZZY' sand box, we implemented the floating oval 'Create New Log' button component at the bottom of the screen. When describing this feature to you initially, I said something along the lines of 'have it start as a circle, upon hover have it expand into a longer oval shape that displays an array of icons, each pointing to a different type of content type to then be clicked on and allow for the creation of a new document - weather it be spark, article, photo gallery, post, whatever. You didn't do it exactly how I envisioned it, but I actually like the idea you came up with. Have it behave how I explained above - starting with a minimalist "+" circle floating at the bottom right hand side of the screen that is present throughout the entire editors desk - meaning everywhere, all the time. even on pages that have yet to be created but will be in the future. When hovered over, have it expand horizontially into a longer oval shape with an array of minimalistic icons - each repersenting a different schema type - spark thread, article, research note, etc. Not all of them, just the relevant ones. When those icons are hovered over, have them expand into the even larger floating mini-version of that document that can both work functionally at just this level, but also provides an 'expand' button that navigates to that actual publishing page for that particular document in the front end editors desk. The 'Site/Desk/Studio' toggle should be implemented here as well, but each of the redirects should lead/point to the front end version, not the studio version. This feature should allow for the quick creation of schema/document/content types even while working elsewhere in the editors desk. For instance, I should be able to quickly create a new research document while drafting in a spark thread, so on and so fourth.

#5Draft

Edited May 30, 2026 · 2:03 AM

Currently, both drafts and published versions of articles are displayed both on the articles page via the top end nav-bar, as well as in the preview card of the editors desk homepage. Again, in regards to the editors desk, I'm quite fine with this and actually prefer it. This should not be the case on the published/public front end version though (which it indeed currently is - both on the public lander/homepage, as well as the "http://localhost:3000/posts" - which seems to also combine posts and articles. ('Posts' also seem to be non-existent as far as being their own individual entity - both in the editors desk, as well as the public front-end) i understand how this happened, as all of the attention has been paid to sparks, spark threads, and articles - as well as 'sparks' and 'spark threads' being an almost identical concept to 'post' and 'post threads' - though I do indeed want them to be different things. Right now I don't know exactly how I want to explain that, so for now just loosely build out the foundation for posts to be present as their own entity, plug that into all of the different navigation paths/etc, and create the individual log pages for each respectively - posts, articles, spark threads, etc.

#6Draft

Edited May 30, 2026 · 2:14 AM

When trying to import/create a conversation thread into an article via the front end editors desk article publishing suite - when selecting the custom content block (all of this is designed beautifully, by the way.) Regardless of the 'type' i selected at the top, each reference option only points to 'facebookThread' - probably because schema types/set-ups haven't been created/refined for each conversation thread type. Create these files, and make sure each is formatted, styled, and set up to match that particular use case - facebook messenger archives, text thread, facebook comment threads, ('transcript' should be changed to 'in person conversation') etc - once that's done, each selection should then reference only the specific type selected. Eventually, we'll refine all of this to the point where i can simply drag and drop archive files and it will automatically parse/imput the content either directly pulling/applying things like timestamps, display names, profile pictures, media content, etc. We're not quite to that point yet, but that is the eventual goal. Keep that in mind when implementing these changes, or if you're up for it - go ahead and apply them now. The particular conversation I'm trying to upload right now is an iMessage thread, so tell me the best way of going about that. WIth the Facebook Messenger archives/Comment Threads/etc - that will be far more expansive and and complex, at least in the context of how I have that information saved already and the options I have considering that. We'll cross that bridge soon indeed, but once we get there that is. Simply just take its future implementation into consideration while performing these updates, and use the iMessage Thread as a nice little tester example - as its far shorter, only one instance, etc.

Group

Untitled group

#7Draft

Empty post…