Feature Request: Auto-update Images & Versioning

[neynah]

Having used Annotate every day for more than a week now, it has become tedious to update images.

Current work flow:

• I upload images to get feedback from my team.
• Once they leave feedback I make changes to the images
• I upload new images using the app UI
• I then have to delete old images & re-order them

Ideal work flow:

• I upload images to get feedback from my team.
  -Once they leave feedback I make changes to the images
• I upload new images using the app UI
• Images with matching file names would update in the app without me having to delete old images & re-ordering them

It doesn't seem like much but it adds up if I have 30 images(for 1 project) and at least 20 of them have 2 or more revisions. Being able to also see previous versions (with comments) of each image would be incredibly valuable as well.

I think these are the 2 important features that would make Annotate a serious contender compared to Marvel & InVision. I currently use Marvel/Invision for larger projects since they auto-update images & save versions. If my workflow was just as efficient with Annotate, I would definitely use it over Marvel/InVision for every project. It's simple, easy to use, and so easy to share & get feedback from my team.

(FWIW, I can help mock-up some UI if you decide to move forward)

[paulproteus]

Can you clarify what "auto-update images" means? When I see text like that, I think, "When I save an image file on my laptop, Invision adjusts its web UI to contain that new image." By contrast, based on our in-person discussion, I think you mean:

• As a graphic designer attempting to get feedback,
• After reading feedback in a web-based feedback tool,
• I edit image files on my computer,
• And then, in order to publish new versions of the same image in the same web-based feedback tool,
• I visit the web-based feedback tool and it offers me a file upload button,
• And then I upload a file with the same filename as a file already in the web-based feedback tool,
• And the tool detects the filename is the same, so it replaces the old image with this name to now show the new image of this name, keeping it in the same order as it was before.

@neynah is that accurate? I just thought I'd spell it out in a vaguely https://cucumber.io/-esque way to help make sure we're all talking about the same thing.

[paulproteus]

@neynah - a related implementation question - in your preferred workflow, what happens to existing annotations after doing the above-named steps?

[neynah]

@paulproteus I don't mean saving an image and having it update in the app at all. So yes, I mean that when I upload a new image (by dragging and dropping it in the "upload image" UI in the app) that it'll update the image with the same file name. Basically just replacing it.

I guess I don't know any mock-up/image annotating application that does the "When I save an image file on my laptop, Invision adjusts its web UI to contain that new image" type of behaviour. But thanks for clarifying in case anyone else experiences some confusion. :)

(I added some clarification in the original post)

[neynah]

If Annotate saved previous versions of images then I would expect the annotations of those versions to also display. Version 1 is displayed with comment A, Version 2 is displayed with comment B and C, and so on. The newly uploaded image would not have any Annotations displayed until someone adds one.

If Annotate did not save and preview previous versions but did still automatically update the images (after I upload it to the app) then I would expect all annotations of that image (with the same file name) to remain displayed. But perhaps time-stamped / visually displayed as older.

[simonv3]

This is cool.

Saving older versions for annotation would probably be a cool feature. This would require some restructuring of how images are stored, but I don't know if it'd be really hard. I'm not sure if I can make it backwards compatible though (at this point that might not be a big concern, and a version number bump would probably indicate that well enough). At the moment the original filename is stored, but it's all just part of an Images collection (which is just FS).

Something I think is interesting here is that I update my filenames when I'm working on them (bla_v2, or bloo-2016-04-07), so that wouldn't work in that flow.

For that reason - I also think dragging and dropping an image over an existing image should update it (with possibly a console warning saying that's about to happen). What do you think of that? There should probably also be an "update" button for each image.

[neynah]

Hmm. I think drag & drop over an existing image is an improvement but I'd still have to drag & drop & confirm them 1 by one. Ideally, it'd be amazing to be able to drop a batch of images & have those update. Hypothetically, if older versions of the image were still saved then it's pretty safe to not have a console warning since it's a non-destructive action.

Would I drag & drop over the image itself or the thumbnail (in the nav?).

[paulproteus]

Two thoughts here:

1. If something is undo-able, then requiring confirmation isn't essential,
   in my opinion. So maybe that would address @neynah's desire for speedy UI
   with @simonv3's desire for people to avoid mistakes.
2. Breaking backwards compatibility is a little sad, so I thought I'd try
   to brainstorm some options for maintaining it. Would it be possible to
   import old-style images in a migration, so that they are considered
   "version 1" of the image? If you're going to break backwards compatibility,
   it's nice to make the non-backwards-compatible app have a slightly
   different name in the app market, along with a different app ID, so that
   auto-updates don't mess anyone up. Also/alternatively, you can detect that
   this is an old-style database and show a message saying that this new
   version can't annotate the old-style data, and also provide a link to the
   user to help them downgrade... then again I don't know what form that link
   would take. Another idea is to show the old data, and not permit any new
   annotations. I dunno, those are some ideas.

[simonv3]

Exciting news! The current master has this functionality in part!

What's in it:

• Uploading an image that has existed in the past will replace that image in the view.
• New images will inherit names and ordering.

What's not in it:

• Actually being able to view old versions of a design. They're there, I just have to figure out a way of switching to view them all.
• Dragging over an existing image with an image file and updating that specific image.

If you want to have a look at the master branch and check it out, I'd love to hear what you think.

[paulproteus]

FWIW,​ Simon, the easiest way for me (or probably @neynah) to experience this is if you are willing to build an SPK we can play with. You don't have to, but that does make things noticeably easier!

[neynah]

Pretty amazing that you made these changes. Thanks @simonv3. Looking forward to playing with the SPK(if possible)!

[simonv3]

sounds good, I'll package hopefully by Thursday :)

(there is an Internet Situation)

[simonv3]

Like promised: https://github.com/simonv3/annotate/releases/tag/v1.3.0

[simonv3]

I've just submitted a package to be published with a couple of fixes to the above spk as well!