sergiomrebelo / evo-poster Goto Github PK

The evolutionInterface.js component appears to be overly extensive and contains repetitive code. It would be beneficial to divide it into smaller, more manageable components.

Root directory is usually for

• README
• LICENSE
• configuration files: package*.json, and others (like eslint)
• src/lib/other top-level directory for source
• test directory
• bin/examples/ others
• doc directory for documentation

it's probably best if you follow that convention, even if it's not intended (hopefully yet) to open source it.

This issue aims to define the preliminary setup for testing the system. The experimental setup will involve creating a diverse set of test scenarios, each representing different design requirements and constraints. These scenarios will cover a wide range of poster design possibilities, allowing us to assess the system's capability to generate designs that meet different criteria. In the end, we will select a experimental setup to further testing it. The definition of these data includes the definition of testing text and emotions.

This issue concerns the modularization of the Cypress testing framework and the integration of functionality to externally load data. The primary objective is to enhance the organization, reusability, and scalability of the testing suite while facilitating the dynamic inclusion of test data.

Fixes on project architecture

• enable rollup automatically serve production files
• integrate p5js (canvas) with rollup

This issue pertains to the development of a hierarchy-based method for handling aesthetic evaluation. In this approach, instead of assigning weights, users define a hierarchy of measures to prioritize and satisfy.

Currently, the mutation method is a uniform method, i.e. each gene has the same probability of being changed. During its evolution, it equally modifies genes related to the typesetting of posters (e.g. font size) and visuals (e.g. background style). Nevertheless, each gene influences the evaluation factors differently, and we have empirically observed that when certain evaluation values are achieved (especially constraint values), there is no necessity for the mutation to still change certain genes too often.

To address this, we propose developing an adaptive mutation method that will enable the system to dynamically adjust gene's mutation probabilities over time. This enhancement will optimize the evolution process and improve the effectiveness of automation tasks with this system. You can find related user stories on automation issues, such as the stories of Jeremy O'Quinn (#2), Kirsty Frazier (#3), and Amelia Chase (#3).

The development of this issue also concerns the refactoring of the mutation method into smaller parts for better maintainability and modularity.

To-Do List

• Implement the adaptive mutation method in the system, ensuring it modifies the probabilities of each gene over time, based on the current overall evaluation of outputs.
• Refactor the existing mutation method into smaller, modular parts for better maintainability.
• Test the overall system performance with the new adaptive mutation approach, comparing it to the previous uniform method.

Issue: Design and Develop Interface for Selecting and Modifying Evolutionary Posters

To design and develop an interface that allows the user to select one of the evolutionary posters generated by the system and modify its style features parametrically. This functionality will enable users to customize the appearance of the selected poster according to their preferences. This issue is related to the exploratory nature of the system, especially users' stories of Jeremy O'Quinn #2, and Amelia Chase #4.

The development of this interface should be aligned with the design of the interface for defining initial features mentioned in issue #16

Currently, the system features a preliminary version of the Semantic Visual Measure. This version allows users to establish a desired set of colors and typographic tags for the generated outputs through a specific configuration file in the evaluation module, named semantics-visual.config.js (see issue #54)

The system then verifies whether these preferences align with the classification results.

However, this issue requires additional development to improve the quality of the results, including secondary classification results, classification scores, and background styles into account.

This is an enhancement of the project. However, it can contribute to the increase of the quality of designs, being aligned with all users' stories.

Problem: The current front-end code and repository structure require fixes to enhance clarity and it is difficult of replication. For instance, the repository's organisation includes a mix of development and deployment files in the public folder. We also will use LitElements library to improve the maintainability and scalability of the project components

ToDo

• Redesign of Repository Structure: We will restructure the repository to improve its organization and make it more intuitive to navigate. This will facilitate better understanding of the codebase and streamline replication processes.
• Transition to LitElements: We have made the decision to adopt LitElements for creating front-end templates. This transition involves converting existing vanilla JavaScript components to LitElements, without utilizing the shadow DOM.

In general, SOLID is a, well, solid methodology for software engineering. There are others, but this one contains a good set of principles to work on. The S is the single responsibility principle. It basically says that a function, class, module should do a single thing. This allows for loose coupling, independent testing, but a better "defensive" programming that saves you trouble when you have to refactor (which you will, sooner or later)

This:

has several issues:

1. Generally, having a default value for an argument is not a red flag. It is, however, if there's an if inside and it changes behavior. Here:
   

   evo-poster/src/index.js

   Line 78 in efaaaaa

   if (sentences.length === 0) sentences = (await NLP.sentenceTokenizer(text)).flat();

   
   you're calling sentenceTokenizer. That means that it's actually a flag to work in a different way; it will tokenize the sentence or not depending on that. It's got two responsibilities then: classify, and tokenize.
2. sentences has two responsibilities. If empty, it's a flag that will tell you wether to tokenize or not. If not, it will skip some functionality.
3. Worst offender however is to make this return HTTP status. An analyzer should analyze. It will either work or not. If it does not work, it should throw an Error. That Error will be captured at a higher level, and interpreted in terms of the intended API, either REST or otherwise.
4. The fact that you put everything in a single file would go hand in hand for worst offender status. This handles the routing, functionality, as well as the underlying analysis functionality.

As I said in #3, every issue should describe a problem. This describes a very general problem indeed. It's up to to you to decide on the solution, either piece-wise (focus on the file, functions mentioned) or general (think about user journeys, user stories, and how to start working on this specific funcitonality -- analysis -- responding to user's needs).

We can talk about it tomorrow anyway.

The purpose of this issue is to conduct a comprehensive review of the scope (private or public) of functions and variables within the project, particularly within the controllers scripts. While some methods have been appropriately transitioned to private, the scope of some public variables has not been thoroughly checked.

This is an enhancement task is crucial for maintaining code clarity, preventing unintended access, and promoting encapsulation. This task also includes the refactor of the system to using loadash to handle certain methods.

This issue concerns the evaluation of initialization method as well the constraints on their ability defined thought the initial evolution interface (see issue #26) The interface serves as the primary user interaction point, allowing users to define initial features of the outputs.

We use cypress to read with visual testing features.

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

Conduct evaluation experiments with Module 1 to satisfy the two major challenges of it: exploration and automation.

In automation tests, we evaluate the capability of the system only on the automation of the preprocessing of contents given by users. On the other hand, in exploration tests, we also evaluate the system value of creating innovative designs and aims in the designers' exploratory processes.

Automation testing

Automation testing will consist of conducting the following tasks:

• Select some quotes (e.g. 10, each one with multiple images) in several languages (pt/es/en) and preprocess them.
• Run task 1 multiple times (e.g. 10) and observe if the outputs are the same.

Exploratory testing

Exploratory testing will consist of conducting the following tasks:

• Select some quotes (e.g. 10, each one with multiple images) in several languages (pt/es/en) and preprocess them
• Run task 1 multiple times (e.g. 10).
• #13

We are using Rollup as the bundler for our project. The assets files, such as images, fonts, or other static resources, are not being properly served, in the build folder, when running the project locally.

The current tournament selection chooses the two parents independently. This way, it always selects the best parent and, it can promote a greedy evolution of individuals. This issue is even more important since we are working with small populations (see issue #43).

This issue concerns the refracting of the selection method to create a method that returns the two best individuals of the tournament. It is an improvement on the system aligned with the user stories that comprise the use of the system with exploratory purposes.

Considering the project's nature, the uniformity measure described by Harrington et al. (2004) is not suitable. This measure holds significance solely within the scope of evolving images, as we confine the textboxes to maintain uniformity on the posters' canvas.

its implementation can only be pursued once image evolution is running without any bugs or errors

To find an alternative when it is necessary to conduct a line-by-line emotion analysis. I found a bug in the other version and currently its works in a recursive way (bad performance and slower in long texts).

When evolving posters using both P2D and WEBGL rendering, after approximately 500 generations, the images within the posters disappearing. This issue is consistent across both rendering modes, and the problem becomes particularly severe when using WEBGL rendering, leading to the entire canvas breaking.

Console traced error on WEBGL mode Too many active WebGL contexts. Oldest context will be lost.

If this is a test, use a testing framework.

We can talk about that tomorrow, and work on it, if you want.

using cypress for it.

The inclusion of textareas (stylised with bootstrap) sometimes creates a warning concerning the use of a percentage number in the definition of the textarea width.

Error: content.js:2 Error: attribute viewBox: Expected number, "0 0 100% 4".

This is something that a proxy trying to tap the API could return.

Check this for instance. 500 says "I can't do anything with your request because I'm not working". That excludes returning a 500 status, because if it returns that status, it's working.

Develop an interface that enables the users to select the characteristics of the evolutionary algorithm. Aligned with the user stories from Bertie Stack (#1), Kirsty Frazier #3, and Kamil Velez (#5).

ToDo

• define evolutionary Algorithm features
• display data about the evolution (no. of generations)

The last row of canvas gallery sometimes is cropped or cut off, causing a portion of the content to be missing from the final output. The problem is not present in all sizes and formats.

The current version of the frontend project is developed using Browserify as a bundler, which is currently outdated and not aligned with the current JavaScript development requirements. For instance, Browserify was not designed at a time when modular JavaScript was natively supported by browsers, and it does not optimize the build size of the bundle.

We will use Parcel due to its simplicity and quick setup. We are using Rollup.

Technical issue related to the performance of the application.

• #19

Further evaluation on lexicon model. Based on the line division the global emotion is different. Check if it is due to the stochastic nature or not.

This issue focuses on creating evaluation metrics to assess the legibility and grid size appropriateness within a poster design container. These metrics will be the constraints in the fitness assignment scheme of the system, ensuring that generated designs satisfy certain readability.

To-Do List:

• Legibility Measure: Develop a metric to evaluate whether the text within the poster design fits appropriately within textboxes, avoiding any overset issues. Develop several modes, including one that try to justify the text.
• Grid Size Appropriateness Measure: Create a metric to assess whether the grid size used in the poster design aligns with the container's dimensions, ensuring optimal layout and composition.
• Define Constraint Evaluation Strategy: Define a strategy to incorporate the legibility and grid size appropriateness metrics as constraints within the fitness assignment scheme of the system.

This issue focuses on the development of design aesthetics measures to evaluate the compliance of output designs with the expected aesthetic standards.

The measures will be related to both visual and typography features of the outputs, including text and images. It is acknowledged that output may not fulfil all features simultaneously. The development of these features will include the creation of an interface to select the desired features and their respective weights. This is considered a core part of the project and aligns with all user stories.

ToDo List

• Justification: Estimate whether the text is justified in the poster's space. Inspired by 19th-century posters, the white space on the poster should not be excessive. This metric is very similar to legibly and have two modes: JUSTIFY and ATTEMPT_JUSTIFY.
• Alignment: Estimate if the horizontal alignment of text boxes follows a regular pattern. See Harrington et al. (2004).
• Regularity: Estimate if the vertical alignment of text boxes follows a regular pattern See Harrington et al. (2004).
• Visual Balance: Estimate the visual balance (centred or left-right) of the composition. See Harrington et al. (2004) and Lopes et al. (2023).
• White Space Fraction: Check if the white space is in accordance with a predefined value. Traditionally, white space (including margins) should total half of the page area. See Harrington et al. (2004).
•  Typeface Paring: Check if the typeface used on the poster pairs well. It will use measures such as x-size and type of typeface. This may require developing a method to include this information in the system (see issue #45). See Bringhurst (1992) and Lupton (2004)
• Colour Accessibility: Check if the colour contrast and luminosity are sufficient to enable the message to be read on a poster.
• Develop module evaluation tests for each metric using jest.

Currently, the configuration of the system mostly relies onParams.js. However, there are instances where some parameters are defined in the code and the current state of the config file is confusing. Thus, this issue addresses the need for the development of a unified way of creating a config file for the system. As documented in users' stories, the system is a multipurpose system. Thus, it is essential to provide users with an easy and fast manner of parametrising the system according to their needs.

ToDo

• Review the existing configuration structure and identify inconsistencies or redundancies.
• Define a clear set of parameters that can be customized through the configuration file.
• Test the new configuration system thoroughly to verify its effectiveness and ease of use.
• Provide clear documentation and guidelines on how to utilize the configuration file for users' convenience.
• divide the entry point form app.js

The objective of this issue is to develop a set of methods for evaluating the quality of poster designs. The evaluation process will consider both mandatory requirements and a fitness assignment scheme to assess each design.

The mandatory requirements include ensuring the readability of the poster design. The fitness assignment scheme includes the aesthetics and semantics of each poster.

ToDo

The following methods need to be implemented for evaluating poster designs:

• Method to Evaluate Readability (see issue #46)
• Method to Evaluate Layout Semantics (see issue #54)
• Method to Evaluate Design Aesthetics (see issue #56)
• Fitness Assignment Scheme: Develop an evaluation scheme that experiments with a stochastic ranking to handle constraint and multi-criteria fitness assignment to handle fitness.
• Interface: Update the evolutionary interface to change the weight of fitness

Code must go in the src directory, for instance.

To design and develop an interface that allows the evolution of poster designs. The interface should facilitate multiple visualizations of the population of posters and provide the user with the ability to lock specific features of the poster during the evolution process.

Currently, the interface is designed for evaluating the representation of posters. However, it needs to be enhanced to meet the requirements of the project's exploration phase, which includes incorporating the feedback and user stories from Bertie Stack (#1), Kirsty Frazier #3, and Kamil Velez (#5).

ToDo

• Results Presentation: Design and develop an interface that displays the generated posters, enabling users to visualize the results of the evolution process and understand the evolutionary progress.
• #26
• #29
• #38
• #42

Interface to setting the initial features of posters. The same interface will be used after to fine-tune the individual (it should use tabs to change between styles).

• initial interface using one tab
• toggle the visibility of interface
• select texbox features (uppercase and text align)

This issue focuses on developing semantic layout measures building upon the analysis conducted in the first module of the project. It will prioritise the visibility of the most important parts of the content, considering font size, font weight, font style, and colour. It is a core part of the project, being aligned with all users' stories.

To-Do List:

• Semantic Layout Measure: Develop a metric to evaluate whether the most important parts of a text (the ones which have more relation identified) are valued in layout.
• Semantic Visual Emphasis Measure: Create a metric to assess whether the typography features (font, weight and vertical motion) of posters where aligned with the emotional analysis of the content, considering that the most important parts of the content must be the emphasis. Include a typography crime mode, which enables penalty designs with too much emphasis.
• #57
• Develop mode evaluation test for each metric (using jest).

Document the resources, architecture, API endpoints, and evaluation results of Textual Analysis module. The documentation should be created on the dedicated page on project wiki.

This issue include the documentation of NLP_utils module

The current initialization method used in the project fully randomizes the selection of background and text colours for the generated designs. To increase the exploratory (see user stories) value of the project, we want to enhance this method by adding preliminary information about the colour selection.

The objective of this issue is to define and implement a more robust system log method within our software application. The system log is important to understand how the system works. This way, it is important in all users' stories. You should check external services, such as Winston, or use localStorage/database to save the logs.

ToDO

• Log the results to file
• Log system running statistics (see Winston
• Review the scope (private or public) of functions, particularly within the controllers scripts.

Develop a method that generates new poster designs randomly at the start of the evolution process.

ToDo

• define representation and codify genotype (class Poster).

• define Population class and its initialisation methods

• create and initialise posters' grid

• method to initialize background colours styles and define the styles

• method to initialize general typographic features (colours and vertical text align).

• define typefaces and styles

• Render posters in WEBGL

• Verify if styles rendered as expected

• Restrict the typography styles based on typeface

• Poster size not defined as expected [bug]

• define the three background styles

• add loaded images on posters

• font loading problem