The application is designed for creating mock-ups. Create product mock-ups with the online mock-up generator. Simply select a mock-up, upload your design and download a watermark-free image.
Recommendations, questions, opinions, feedback.
- Development
- Dictionary of Terms
- Software requirements
- Deployment
- Remarks
- Literature
- Useful documentation
Tracking of tasks was done using GitHub Projects.
The development of the project was divided into several stages:
- Development of software requirements.
- Design development.
- Module development.
- Application development.
Before starting to develop the code base, the requirements to the software product were thought over. Functional and user requirements, quality attributes were formulated; a data dictionary and a dictionary of terms were compiled. Read more about the requirements for vital software in the chapter «Software requirements».
A unique identifier is created for each requirement. At the stage of code writing, the identifier of the implemented requirement is noted in the comment, which makes it easier to find the implementation of a particular requirement in the code base. For example:
/**
* @requirement REQUIREMENT/ID
*/
async function sameName(): Promise<void> {
...
}In the book «Software Requirements Engineering» by Carl Wiegers and Jay Beatty, this approach is called requirement tracking. To find anything related to a particular requirement use the codebase search (⇧⌘F in VSC on macOS) and enter the requirement ID. For example:
The design of the application was developed in Figma/Photoshop. The design was developed in accordance with the previously developed software requirements.
The application implements a «modular monolith» architecture. The project is separated into modules and application; modules are responsible for implementing the business logic; application is responsible for rendering the UI and executing the business logic through the modules. Thus, the application (in this case, the NextJS framework) is responsible only for displaying the UI, while the modules contain all the business logic. Each module performs only one task and should not interact with other modules in any way. Not all modules implement the subject area - general purpose modules are allowed.
The purpose of this separation is to separate business logic from fickle and windy frameworks and libraries that have nothing to do with business logic. The modules are designed in such a way that they can be used independently of the framework; this makes it very easy to migrate from ReactJS to VueJS, for example.
If you're using macOS or Linux (Doesn't work on Windows¹), you can use the tool to quickly create and configure a new module; run this command in the root of the project:
bash cli/module_creator.bashAt the moment there are 4 modules implemented in the project:
| Module name | Meaning of the module | Implements the subject area? |
|---|---|---|
| @mock-up-canvas-image-generator | The module is designed to generate an image based on the renderData object. | + |
| @mock-up-state-generator | The module is intended for mock-up state management. Includes device selection, image insertion, device settings. | + |
| @feedback-creator | The module is intended for sending feedback by the user. | + |
| @html-image-downloader | The module is designed for downloading images. | - |
Detailed descriptions of the modules and examples of their use are provided in the modules' documentation.
To change the logic of module operation and check the result of its work in the application, you need to recompile the module. This can be done using the build_modules script; execute this command in the root of the project:
npm run build-modulesIf something went wrong, you can compile the modules yourself. To compile a module yourself, go to the module folder and execute the compile command:
npm run compile«When building interactive applications, as with other programs, modularity of components has enormous benefits. Isolating functional units from each other as much as possible makes it easier for the application designer to understand and modify each particular unit, without having to know everything about the other units.
Model-View-Controller metaphor and its application structuring paradigm for thinking about (and implementing) interactive application components was developed. Models are those components of the system application that actually do the work (simulation of the application domain). They are kept quite distinct from views, which display aspects of the models. Controllers are used to send messages to the model, and provide the interface between the model with its associated views».
«A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System» Glenn E. Krasner and Stephen T. Pope
An architecture is developed where modules play the role of MVC models. Controllers use module methods; one controller can be linked to several modules; controller serves as a link between modules and view; controllers are not linked to the framework and are just classes, so they can be reused with any other framework to render the view. View calls controller methods and knows nothing about business logic.
The structure of the project is a modular monolith.
«The modular monolith is a variation as a subset of the single-process monolith: a single process consists of separate modules, each of which can be worked on independently, but all of which must still be combined».
«From monoliths to microservices» by Sam Newman
Controllers combine the necessary modules to solve business problems and export ready-made methods to solve business problems.
Compositions modules are modules consisting of UI and controllers linked by a single business task.
UI and business logic are placed in a single module for convenient work on a specific business task and do not have any dependencies with other business tasks. Composition module exports external business task methods and UI components with ready business logic for rendering in the application
A similar move can be observed in the book «From Monolith to Microservices» by Sam Newman, but this approach was called there as «ui modules»
You can read more about this paragraph here /app/yamu-react-app/README.md.
To install the repository, paste this command into your terminal:
git clone https://github.com/hschhhwwwo0o/yamu.gitIf you are a macOS or Linux user, (Doesn't work on Windows¹) the project installation is done in 1 line of code in the terminal; to install application and module dependencies, copy this command and run it in the project root:
bash cli/project_installer.bashIf the install script gives an error (Doesn't work on Windows¹), you must install the module dependencies yourself, compile the modules, install the application dependencies, and install husky to install it.
Start the dev server using the command in the root of the project:
npm run dev«A dictionary of terms defines all the specialized terms that the reader needs to know in order to properly understand the software requirements specification».
«Development of software requirements», Third Edition. Carl Vigers, Jay Beatty
The term dictionary is intended to ensure that the same terms are used throughout the code base. For example, to eliminate the use of synonym words.
| Term | Meaning |
|---|---|
| Export | The process of saving a layout to a file or to another format that can be used in further development or use. |
| Devices library | A collection of devices available for creating mockups. |
| Mock-up settings wizard | Mockup settings panel consisting of several steps. |
| Mock-up preview | Mockup display. |
| Mock-up preview scene | The scene in which the mockup is displayed. |
| Selected device | The device selected for the mockup. |
| System bar | The system panel, usually located on top and displaying network data, time, and so on. |
| Inserted design | An image of the application design intended to be inserted into the layout. |
| Frame | Imitation of the device case. Within the framework of the tool, the frame is used as an application design container. |
| Device type | Watch, Phone, Tablet. |
| Device | Real device; phone/tablet. With a refined model. |
| Mock-up | An application design placed inside a frame and displaying how the application design will look on real devices. |
| HIG | A set of guidelines for designers. |
| WCAG | A set of guidelines on how to create an interface and how to check its accessibility for users with disabilities. |
| Open Graph | Micro markup for SEO. |
| Lighthouse | Automated tool for measuring the quality of web pages. |
«Requirements are a specification of what needs to be implemented. They describe the behavior of the system, the properties of the system or its attributes. They can serve as constraints in the system development process.»
Ian Sommerville, Pete Sawyer, 1997
«Quality attributes describe the characteristics observed during software execution. They strongly influence the perception of the system by users and the opinion that users have about its quality.»
«Development of software requirements», Third Edition. Carl Vigers, Jay Beatty
| Attribute | ID | Description / Why it's necessary | Done |
|---|---|---|---|
| Separation of the mock-up creation process. | QA/MOCK-UP/CREATE-STEPS | Separation the process into steps is necessary for a better UX. | ✅ |
| UI is based on HIG. | QA/UI/HIG | HIG is essential for a better UX. | ✅ |
| Localization. | QA/LOCALIZATION | Localization is necessary because the product can be used by foreign users. | ❌ |
| Interface adaptation. | QA/UX/ADAPTIVE-INTERFACE | An adapative interface is needed to better display the app on different devices. | ✅ |
| WCAG compliance. | QA/UX/WCAG | WCAG is needed for a better UX for people with disabilities. | ✅ |
| Error output. | QA/UX/ERRORS-LOG | Necessary for a better UX. | ❌ |
| High Lighthouse testing results. | QA/SEO/LIGHTHOUSE | Necessary to improve search engine rankings. | ✅ |
| Open Graph support. | QA/SEO/OPEN-GRAPH | Necessary to improve search engine rankings. | ✅ |
| Description of standard meta tags. | QA/SEO/META | Necessary to improve search engine rankings. | ✅ |
| Twitter meta tags. | QA/SEO/TWITTER-META | Necessary to improve search engine rankings. | ✅ |
«Functional requirements can be written in terms of what the system does or what the user does.»
«Development of software requirements», Third Edition. Carl Vigers, Jay Beatty
| Functional requirement | ID | Responsible element | Done |
|---|---|---|---|
| Sending feedback. | UF/FEEDBACK/CREATE | @feedback-creator | ✅ |
| Downloading a mock-up. | UF/MOCK-UP/DOWNLOAD | @html-image-downloader | ✅ |
| Mock-up image generate. | UF/MOCK-UP/IMAGE-GENERATE | @mock-up-canvas-image-generator | ✅ |
| Render mock-up. | UF/MOCK-UP/RENDER | @app | ✅ |
| Getting affordable devices. | UF/DEVICES-LIBRARY/GET | @mock-up-state-generator | ✅ |
| Choosing a device. | UF/MOCK-UP/DEVICE-SELECT | @mock-up-state-generator | ✅ |
| Adding an design inside a mock-up. | UF/MOCK-UP/INSERT-DESIGN | @mock-up-state-generator | ✅ |
| Reset the mock-up. | UF/MOCK-UP/CLEAR | @mock-up-state-generator | ✅ |
| Mock-up initialization. | UF/MOCK-UP/INIT | @mock-up-state-generator | ✅ |
Setting up a mock-up. |
UF/MOCK-UP/SETTINGS-UP |
@mock-up-state-generator | ✅ |
| Getting available settings. | UF/DEVICE/GET-SETTINGS | @mock-up-state-generator | ✅ |
| Switching the device's system bar. | UF/DEVICE/OPTION-SYSTEM-BAR-TOGGLE | @mock-up-state-generator | ✅ |
| Switching the theme of the device system. | UF/DEVICE/OPTION-THEME-TOGGLE | @mock-up-state-generator | ✅ |
| BW color correction mock-up. | UF/MOCK-UP/OPTION-BW-STYLE | @mock-up-state-generator | ✅ |
«A use case describes how to use an automated system. It determines what the user should enter, what should be output in response, and what actions should be performed to obtain the output information.»
«Development of software requirements», Third Edition. Carl Vigers, Jay Beatty
| ID | UC/CREATE-MOCK-UP |
|---|---|
| Acting person | User. |
| Description | The user selects the device for which he would like to make a mock-up. Configures the mock-up with subsequent download. |
| Output conditions | UC/CREATE-MOCK-UP/POST-1. The system asks for feedback. |
| ID | UC/CREATE-MOCK-UP/POST-1 |
|---|---|
| Acting person | User. |
| Description | The user enters their feedback in the text box and submits it by clicking on the button. |
| Output conditions | UC/FEEDBACK/POST-1 The system notifies the user when feedback is sent. |
| ID | UC/FEEDBACK |
|---|---|
| Acting person | User. |
| Description | A user enters and send his/her feedback about the service into the text field. |
| Output conditions | UC/FEEDBACK/POST-1 The system notifies the user when feedback is sent. |
| ID | UC/FEEDBACK/POST-1 |
|---|---|
| Acting person | System. |
| Description | The system notifies the user when feedback is sent. |
Deployment requires:
- Install all dependencies.
bash cli/project_installer.bash- Compile the application.
npm run build- Run infinite loop / specify out folder.
To implement with the start of an endless loop, execute the command:
npm run startTo implement by specifying the output folder, specify the path: ./app/yamu-react-app/out.
Exaple on Vercel:
¹ If you are a Windows user, you can probably use WSL to work with unix commands.
The development process was strongly influenced by the books:
- «Development of software requirements» Carl Vigers, Jay Beatty;
- «Clean Architecture» Robert Martin;
- «Envisioning Information» Edward R. Tufte;
- «A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System» Glenn E. Krasner and Stephen T. Pope;
- «From monoliths to microservices» Sam Newman