What is this project?
This project is a ground-up implementation of an online drawing tool called Mini Draw, primarily using React and its libraries. The most prominent feature of this project is real-time collaboration, with the ability to have multiple users contribute to one file/project.
This project was developed as a class assignment with a group of 3 members from backgrounds of software development, design, and HCI. We took inspiration from the prototyping tool Figma, which also includes features like a layers list, drawing, resizing, and real-time collaboration on one file.
An overview of the project's technical capabilities
Shape Selection and Movement
Our project supports the ability to drag and draw shapes like rectangles, ellipses, polygons with varying vertices, and objects like text boxes with custom text.
The Layers panel shows order of visible objects by their z-index. The Actions panel on the right shows commands performed like objects deleted or edited, undo/redo etc.
All commands or actions are undoable, redoable, and repeatable (condition permitting). Workspaces can be reset, meaning project progress can be erased by the ‘Reset Workspace’ button.
Objects can be edited by changing border width, border/fill color, vertex count, and shape/text output.
The application allows creating workspaces that can be renamed, added, or deleted. The workspace is laid out with a drawing space, controls panel and main navigation at the top of the screen.
The application supports collaborative editing, so multiple users can work on the same workspace at once. We retained undo/redo, repeat actions as individual features to prevents accidental editing and lost progress.
How the system works, programming libraries used, database storage, and real-time updates
We used 3 main libraries to code this project:
We used the React Router to handle navigation, information transfer between pages, and display of components.
We used Google Firebase to store information about workspaces, objects in each workspace, and its properties.
Managing the Database
Firebase structure and usage
We used Google Firebase to store all the information about our workspaces so users could start on a project, save their progress, and pick up from the same spot in their project later.
This allowed multiple users to view real-time updates on a project, encouraging multi-user collaboration. We structured these saved projects as workspaces, in which content/progress from each workspace is saved as a document and shapes within each document are saved as a field (workspace data) along with the workspace name and user.
Within our base implementation's code structure, we created a firebaseContext file to store all the functions related to firebase initialization and modification.
Flow of information between functions and pages
Changing data without manually running code
The logic to update workspace data in Firebase is placed in componentDidUpdate, which runs every time the React state changes, without having to call it manually in every function.
We created a disableUpdateFirestore state to prevent updating Firebase too many times. While displaying actions like slider-based changes could be useful to see visual differences, accessing the database every time would cause too many logs to the database and eventually crash the program. To avoid issues, we only access Firebase when users finalize their actions.
Flow of functions (logic) to handle accessing Firebase
The reasoning behind our design decisions
The overall aesthetic is simple and straightforward, with feedforward design for buttons (drop shadow to prompt clicking), and a consistent color palette to keep the attention on the main workspace instead of the application’s color scheme.
Our current design is laid out according to ease of use and quick access to each command. Since a screen is generally viewed from left to right, we arranged the most important element, the drawing/editing workspace, to the left-most part of the screen and placed the controls and visual panels on the right side of the screen for intuitive access. The individual buttons and modes in the control panel follow a simple aesthetic to make them look clickable.
Previously, we did not include a layers panel but allowed users to send shapes forward and backward. Testing the application helped us realize that it was difficult to gauge the order of objects on screen without a visual aid. This panel also had an unintuitive ordering method with the topmost object at the bottom of the list; we reversed this ordering as well.
To make it easier to view and change the order of objects without having to find the buttons for it, we moved the layers panel to the rightmost part of the screen, below the actions panel, allowing for more screen real estate for the drawing workspace.
Color Picker Confirmation
Initially, we did not have a confirm button for color pickers and updated the palette view when a new color was selected on the palette. This caused issues when multiple colors were browsed through, since it accessed and logged multiple different colors to the database, further causing issues with undo, redo, and repeat actions. To make sure a color was logged only when finalized, the confirm button was introduced.
Local Command List (Actions Panel)
Since our application’s main appeal is multi-user collaboration, we had to decide between creating a global command list or a local command list for the undo, redo, and repeat actions. As a universal standard, we went for a local command list to avoid crashing workspaces and accidental deletes/edits.
Our rationale was based on Github’s problematic commit actions, where committing directly to a repository instead of a branch can wipe out the previously stored files and the action cannot be undone. This way, multiple people can work on completely different objects in the same workspace without disturbing others' progress.
A walkthrough of how Mini Draw works
Our vision for this project
Our vision for this application is a collaborative SVG drawing tool like Figma. Given the scope of this project, there were several features we were not able to implement but would like to work on in the future and add to the project, to transform it into a better prototyping tool.
This means the application would allow users to link their Google accounts and log in to view their personal workspaces. We would also like to add an option to set each workspace to public or private views, similar to Github’s permissions system. Each workspace would be able to indicate which users are working on the workspace by displaying their profile pictures and initials/names, like Figma and Google Slides.
We would like to enable private workspaces to be shared with others via links, similar to Figma’s interface, which would allow users to collaborate without sharing the file with everyone outside their workgroup. This would include a share button to generate a link for collaboration.
We would implement this feature by adding another distinct handle alongside the existing eight selection handles, so objects can be dragged clockwise or counterclockwise to be rotated, similar to other drawing programs.
Downloading the Workspace
This would allow users to download the SVG workspace as a PNG file. This way, they can save their changes offline and keep a record of their projects. For example, this feature would be useful to keep a record of design iterations made on a collaborative project.
Real-time Textbox Editing
This would allow users to directly type on the SVG workspace to create a textbox and edit the text by selecting the object.