Next Major Improvement (For Me): Image Handling

I seriously could live with Lettera for a while even as-is with just one major improvement…

When we drop an image into a doc, that image shows up in the root of the parent folder in the sidebar. I honestly don’t want the many docs I’ll create having a list of those images in the sidebar. It will just clutter the sidebar for me, when I don’t expect to see images there—only in my doc(s), just like every other writing app I’ve ever used.

Thanks for listening. Seriously, love this so far. I just need those images hidden :frowning:

7 Likes

Yep, I second the request. Or some more elegant solution … but images listed in sidebar will be very ugly after awhile. Although … if I take advantage of folders the bad effect may be minimized a bit so they don’t need to show up in the main sidebar but only within a folder. Might work for me … not sure though.

Also ran into a bug. Created a folder. Put a document and an image inside it. Renamed the folder. And then … the folder disappeared! Yikes. Found it in the finder … renamed … and it showed up again. This may not be the exact sequence of steps, but something in the folder, put stuff in, rename created a disappearing folder in the sidebar

1 Like

There’s no shame for the devs in checking out some of Obsidian’s options, which are significantly more advanced in terms of accommodating to all the possibilities a user might prefer:

Also check the other options, especially “Default location for new notes”!

3 Likes

Share your setups!

I personally like 1 asset folder per-project to group everything, or co-locate images with text in e.g. blogs, but to make this nice and behave properly and refined, the more we hear about your setups, the better!

3 Likes

In Obsidian I used to do one global assets folder for my vault. A per-project assets folder probably makes more sense in a world not anchored on a single vault.

I actually think they have an opportunity to do something unique here and package the Markdown docs with their images using something like TextBundle. It would make for a better UX for 99% of use cases. The whole “images floating around separate from the doc” limitation of plain Markdown docs is always pain to deal with (even in Obsidian, which has a bunch of options and plugins to help deal with it). Yes, there are some people that take advantage of the ability to link a single image to multiple docs but I think that is an exception rather than the norm.

2 Likes

+1 for TextBundle support

I would much prefer TextBundle format because it bundles the “whole document experience” (text + images + attachments + metadata) into one portable unit, instead of juggling a .md file plus a pile of loosely associated assets on disk.

Result: Its a LOT easier to deal with documents when everything comes as a single package. Easy to manage, easy to share, easy to email, etc. This is a common reason why people still use MS Word for documentation - each .DOCX file is a self-contained entity.

I’d go so far as to suggest that Textbundle be the default file format and “naked” markdown be an option for those that need it.

FYI that Typora has beta support for Textbundle: Typora — dev release channel

Thank you!

2 Likes

Good news @Jasonj @Jason – Lettera supports TextBundle natively. We’ve not shipped ways to create text bundles from scratch with this version though

3 Likes

I put all project images into an [images] directory (no brackets) inside the topic folder and link to them at that location. I copied a number of topic folders from iA Writer’s iCloud directory into Lettera’s iCloud directory and Lettera displayed them perfectly.

I don’t put graphics in project folders. I keep all my screenshots in a dedicated screenshots folder. I have macOS save to that folder, so I can always access them quickly from the Finder sidebar where I’ve added the folder. This folder is on my iCloud Drive, so both my Macs can save files there and access it.

I have Hazel move screenshots that haven’t been modified in two week to an archive folder on my iMac, so I can always go back if need be.

This works for me as a writer, because screenshots are generally one and done; once the article is in the CMS, or sent off to the client, I don’t need access any more.

I second the motion. Image management is a primary reason why I’m looking to replace Obsidian and IA Writer.
I want images to be stored alongside the document so if I delete the document the images go with it. But listing the images in the sidebar adds visual pollution. I can create a folder for images, but then the images don’t get pruned if I delete the document. Also, I still have the visual pollution of an image folder in the sidebar.
There’s bound to be a better way!

hmm, sounds like there’s many workflows and user preferences which is why I think the dev team wanted to be grounded in simply creating a file based markdown editor and let the user decide.

Having said that, since everyone works differently and has legitimate workflow needs, maybe having a default setup with the ability to change how the user wants to configure their setup in Settings seems like an obvious solution. This all depends on how complicated the app needs to be to meet the goals described above.

Maybe if just managing files to meet everyone’s needs wouldn’t be that difficult and is all that’s needed - no idea.

Textbundle sounds like an option for some but not the original intent of having an editor of MD files yet seems like a reasonable request and someone said it’s already supported.

Having a user preference on where to store images, attachments, etc seems like it would solve a lot of user desires.

I definitely don’t like the all images being stored at the root folder as not only will I have 100’s of files for what I’m hoping to do it’s also a lot of noise. Having them reside in the same folder as the MD makes sense provided not more than one MD across folders needs the image. Having an asset folder is another option and maybe the noise is low because they’re all in one folder. I really won’t know personally until I start using it but would want user options to configure it and try it. I know I don’t want to see a long list of assets in the sidebar…that’s too much and feels messy than I’d want to use an app that hide all that or maybe that’s what textbundle will do. I would like the option to hide the noise though especially if alongside the MD files.

My vote is to come up with a finite list of configurable options that are reasonable for the dev team to support and ensure it resides in Settings or whatever makes the most sense.

-tom

Markdown files don’t really support images, they support image paths. You can put images wherever you want; they don’t have to be in the same folder as the file you’re working on. If you do have a lot of images, you just have to deal with them; there are no shortcuts. I have a Screenshots folder on my iCloud Drive, so I can access screenshots for all my articles easily. I use Hazel to automatically move them to an archive folder if they haven’t been modified in ten days. After that point, I usually don’t need to go back to them, and that keeps the folder from containing too many images.

If you do use images in files that you want to access over the long term, it’s still best to have a dedicated folder for them, rather than try and store images near each text file.

I don’t know what text bundle and text pack are; whatever they are, they are not standard markdown, which is simply a text file. So perhaps the devs have created an option similar to RTFD, a .pkg file containing the text file and images, but that wouldn’t be compatible with anyone using different software.

I get that, but how does your response help in any way? Bear, a Markdown editor, allows dropping images into a doc/note and yet the image is not shown in the enclosing tag structure. Sure, Lettera uses folders, but to me a tag is no different than a folder. Bottom line, why should we be penalized with a slew of images in the sidebar when there’s no need for it.

[Lettera devs, I know you are working on things. So disregard my response to this user.]