Image Upload

[sergiomrebelo]

This issue is related to users' stories of Bertie Stack (#1), Kirsty Frazier #3, and Kamil Velez (#5). To evaluatee these users' scenarios the purposed system should allow the input of images, to be included in the poster design and in the typesetting process.

When this issue is closed, the system will allow users to input multiple images into the system, using a dedicated field on the interface.

⚠️ Images files are only loaded into the client-side of the application (as temporary binary files). This system will not save any user information or data during the evolutionary process. ⚠️

It should be possible to load images into multiple formats (jpeg, png, etc.).

As unveiled in user's story #3, this method should allow users (if they want) to define the position of images on text using the text glyph that they want as anchors (in this case, each image has the same treatment that a text line). [challenge: automation]

When not defined, images are placed at random on text and change over evolution [challenge: exploration]

The development of these features includes the development of two validation methods:

• validation of the file format;
• validation if the number of anchors and images matchs.

Note: Random placement of images is defined in the generator module. In this case, image position will be evolved by system.

Tasks

• loading multiple image files
• validation of files format (both format and size); [only format]
• divide text by anchors when text division is defined by user
• divide text by anchors when text division is automatic

[sergiomrebelo]

Line division should also take into attention (Image Placeholder Delimiter)

[JJ]

There are a couple of best practices for issues. They can obviously be used as a simple reminder for doing stuff in the future. However, when you're on a team (as seems to be the case, since it's a PhD, there's at least a team of two, tutor and student), it's better if you follow the convention roughly outlined in my paper, which involves a couple of things

1. "User journey" must be formulated clearly, and from this, some user stories and uses cases must be written very precisely. If this does not exist, it's not clear where an issue fits in; and bear in mind that if it's not clear for me now it will not be clear for you in 6 months time.
2. You must create issues that formulate problems. In this case, you seem to be saying that you need to upload an image, yet you mention a "zip", and it's not clear what you mean. At any rate, you're saying uploading a zip solves the problem, but it's quite clear that if a zip solves it, a .tgz might also solve it. And if any of these can, a multi-file endpoint would do too. But the problem is what do you need the image for? If we don't have the user journey, it's impossible to say.
3. You have not closed the issue, and that's good; you're referring to the issue from the commit messages, thats good++. But closing should only come after a test; and this is why you need tests, which I mentioned in Why don't you try actual tests? #5 . Tests should look roughly the same as the description of the problem, and essentially will answer the question "Is this solved?"
4. Finally, working with pull request is a best practice even if you do it alone by yourself. It's very easy to skip a "refers Image Upload #3" in a commit message; in PRs you'll be working in a branch, and everything will go to that branch. The PR can have additonal tests if needed.

[sergiomrebelo]

I already draft some personas, user stories and scenarios. However, I don't know how the best way is to present it on GitHub. It is one of my questions for our meeting tomorrow. Currently, I have made this available on a database on Notion.

Concerning the documentation of issues: Ok, now I understood. Each issue should be related to the concrete problem and not to implementation. Regarding the upload of a zip file to upload multiple images, in fact, I used a multi-file input endpoint and works without problem.

Concerning the use of PR: Yes. In the last meeting, we talk about the use of PR and dev branches. I will begin to make this soon; However, since I still do not have any module in a functional state, I still working on the main branch.

I already updated the issue description. May you review it and give your thoughts about it?

[JJ]

I already draft some personas, user stories and scenarios. However, I don't know how the best way is to present it on GitHub. It is one of my questions for our meeting tomorrow. Currently, I have made this available on a database on Notion.

Concerning the documentation of issues: Ok, now I understood. Each issue should be related to the concrete problem and not to implementation. Regarding the upload of a zip file to upload multiple images, in fact, I used a multi-file input endpoint and works without problem.

Concerning the use of PR: Yes. In the last meeting, we talk about the use of PR and dev branches. I will begin to make this soon; However, since I still do not have any module in a functional state, I still working on the main branch.

Best practice here is to work in a "development" or "dev" branch until you have something functional. main branch is whatever is in a state that's ready for production

I already updated the issue description. May you review it and give your thoughts about it?

Main issue is that issues should always be attached to user stories; it's difficult to say, without them, if this is OK or not. I would wait for user stories to be written here, but anyway, I'll have a look.

[JJ]

To enable the input of varied images, in the system, to be employed in the poster typesetting process. So, this feature will enable users to be able to input multiple images into the system, using a dedicated interface field.

¿What persona is interested in that? The issue, as always, is that depending on the persona they might want to incorporate them later, using any application they feel familiar with.

Also, the issue is exactly what you use from the images. If it's just the position (which you will use for splitting, for instance), well, that's more than enough. If it's the position and width, it might be not necessary to actually upload them. But if you need to go the whole nine yards and actually upload them, you need to set up some kind of database so that they can be selected once uploaded, and so on...

All in all, I would leave the actual uploading of the images for a (very) late stage or minimally viable product. The amount of effort is not really worth the while.

It does not upload images to the system's server. Images files are only loaded into the front-end application of the system (as temporary binary files). It should be possible to load images into multiple formats (jpeg, png, etc.).

Beyond the input of images, these features will enable the users (if they want) to define the position of images on text using the text glyph that they want as anchors (in this case, each image has the same treatment that a text line). When not defined, images are placed at random on text.

The development of these features includes the development of two validation methods:

1. **validation of the file format;**

Well, that too. You need to validate the format, possibly include just a certain amount of them, maybe check the size, and then of course be ready to actually display them if you are doing an interactive display.

2. **validation if the number of anchors and images matchs**.

Additionally, you need to do that too...

Note: Random placement of images is defined in the generator module. This enables to be evaluated and evolved by system.

ToDo

* [x]  load multiple files

* [x]  validation of files format

* [x]  divide text by anchors when text division is defined by user

* [ ]  divide text by anchors when text division is automatic

The thing is that as soon as you have some notion of "uploading information", you need some notion of "user", and that goes with "permissions" and the whole nine yards. All in all, except for the concept of marking positions for images, I would drop the whole thing and focus on the initial minimally viable products. You can create a milestone that includes this, but for much later.

[sergiomrebelo]

Ok, its makes sense. The question of images was not well defined in the user stories (for me makes sense in personas Bertie Stack (#1), Kirsty Frazier #3, and Kamil Velez (#5). However, I do not put it clary in scenarios.

I just updated the issue description and made available an updated version of user stories. I also started creating a wiki page for documentation of the project and each module.

Concerning the question of images: I just load the images on the client side transforming them into Blob. Since the posters will be evolved on the client side, I think that is enough to develop the MVP. However, I agreed with you. If it becomes very complex, perhaps we can give up on this feature in the first MVP.