Image maintenance, a huge pain (problems and suggestions)

[manavortex]

First of all, I know that I could rename the images more easily on the github repository itself, but doing so will break the embeds (and it's a different workflow).
This is about UX/UI of inline editing.

User story: While editing a wiki article, I stumble upon an outdated image and want to replace it with a more recent version.

The current workflow

1. Finding the image name

1. I click on the image to open it in the lightbox
2. I right-click on the image to open it in a new tab
3. The URL will now include the image name:

2. Finding the image

1. I click on the menu in the top right to open the "Images" tab:

So many new editors ask about this

November 2024

Wow, great, you moved the tab (this is sarcasm, it wasn't really great — it took me >5 minutes to find this)

2. I can use the unique image name from step 1.3 to search for the image

3. I click through 958 images until I've found the one I want to replace
4. To make things easier on future editors, I decide to give the image a proper name.
5. I click on "edit" and change the image name.
6. The image disappears from the search.

3. Editing the image

1. Since I re-named the image, it no longer matches my filter, and doesn't show up in my search results
2. I can use the unique image name from step 2.6 to search for the image
3. The file name no longer has an extension because I forgot to add it. I repeat step 2.6
4. Depending on my filter, I repeat step 3.2 as well
5. Now I can upload a new version of the image!

Proposed solutions

1. Preventing the issue altogether

It is great that I can just paste images, I wouldn't want to miss that feature for the world. But naming everything "image.png" is far from optimal.

Showing a file name dialog on paste

The fastest way to resolve this problem is to trigger the rename dialogue whenever the user pastes a file.

Once auto-naming (see the next heading) is implemented, this won't be as necessary anymore, so you could add a user setting to turn it off.

Auto-naming

Any image that is pasted into a wiki page should be given the name of that wiki page.
E.g., if I'm editing subsection/readme, my files should be called something like subsection-readme.png, subsection-readme-2.png etc.

It would be even better if section headings would be considered: when editing subsection/readme, the current heading hierarchy will also be considered:

Yeah, this will end up in endlessly long file names, but at least they will be very unique!

2. Allow editing from inline

The hover editing menu should

1. show the name of the image and a "rename" button
2. show a "replace" option

3. Better filters

1. The "files" section of the wiki needs better filters. Maybe you can take a look at the Discord filtering logic for inspiration.
   Personally, I'd like to filter by
   • embedding page(s) Use case: Images that aren't embedded anywhere can go
   • uploader Use case: my buddy xyz never crops her files, I'm gonna fix that for her
   • file extension Use case: I want to replace all .wbem with something that isn't wbem
   • date Use case: all images from last year need the company logo
   • file size Use case: Anything bigger than 2MB needs optimizing
   • aspect ratio Use case: We only want to embed 16:9 because we hate mobile users
2. By default, the "files" drawer should open with a filter showing only assets on the current page

3. It would be great if I could easily filter by "parent and sibling pages". For example, if I'm editing subsection/how-to-use, maybe I would like to re-use an image from subsection/user-interface-explained!

4. Automatic handling of file extensions

This should be standardized by the back-end (also avoids .jp(e)g .JP(E)G).

• If the user uploads a file without extension, get it from the mime type and just add it to the file name
• If the user renames a file and forgets to include the extension name... see above

Editing files: UX

rename "Edit"

Right now, the menu item for renaming files is called "Edit". This suggests much more than the thing it actually lets you do:

redesign the UI

Here's how you could make this look:

(It's butt-ugly, but I do UX, not UI!)

[Simarilius-uk]

So much this, pasted images are a pain in the ass with the current workflow.

[zdmilot]

@manavortex I totally agree, the file management for images could be much more improved in their iteration. One solution I have found to be helpful. is managing images via the GitHub integration. All images are located within the ./gitbook/src directory. Do note that changes to names in this may cause issues when it comes to image links being broken so take caution but editing the images in this directory can aid in the management of images throughout your gitbook. I want to add that their AI features are robust enough to be able to do image descriptions as file names. When pasting images in, the "image.png" nomenclature is not sufficient and a more descriptive and unique identifier should be used instead.

Even utilizing numeric suffixes in the user experience display name would be beneficial. Additionally improvements within the images and files section of gitbook should be evaluated. @GitbookIO @SamyPesse There needs to be a more robust file manager to allow for the separation of in-line images/image block images, files and attached documents, and cover images. Separating these into their unique source locations wouldn't be a huge update and would require the creation of two additional directories within the ./.gitbook directory structure. This would segment the needed resources and allow for more robust management of files.

One Additional note/suggestion would be to include within the broken links tool or even separately in its own iteration, the ability to manage images which are no longer within an in-line, block, cover, etc and are no longer referenced within the entire GitBook. This could be an additional directory which images/files which are not linked can be moved to a .gitbook/unlinked_files directory. This would reduce the burden of hosting unnecessary storage and expand upon a robust file management strategy for end users.

Lastly the usage of ./.gitbook for source files should be re-evaluated if possible as the ./ is helpful for internal systems but though GitHub syncing this should be changed to remove the . indicator before the directory name. All directories and files with a . in the prefix are treated as system resources, making managing and maintaining source files for the markdown difficult using Mac/Unix systems.