Now for some thoughts and principles about what went into this project.
Keep The User Interface Simple
The user shouldn't have to think. Everything in a layout should be straight forward, natural, and familiar to the user. Here's my take on that.
Logging in. You start with a login page. You create a user account with a password. If everything goes well, you can log in with the new account. If you messed up the password or tried making an account that already exists, it'll tell you.
Here's what that looks like.
Here's what that looks like.
When you log in to the actual paint program itself, it's time to get creative. After having some fun with it, you might get something like this.
Loading and saving are done through the file menu. It will load drawings and save them based on the name entered in the "File Name" field.
And that's it. It's simple, straight forward, and doesn't try to be clever.
Basic authentication on the client side also must be dealt with by the API on the server side. That helps in managing user-specific data. This setup was somewhat inspired by Github's API. It's simplicity is reflected in the fact that the Requests library uses that API as an example in it's documentation. Flask makes it easy to follow Github's example. Take saving a drawing for instance.
Loading and saving the drawing data was interesting in and of itself. The SVG is XML embedded within the DOMhierarchy. That XML gets converted to and from JSON. SVG.js was used to create the svg data that make up the image on the canvas. On the server side, the data relationships were such that they played very nicely with the SQLAlchemy take on ORM mappings.
Loading and saving are done through the file menu. It will load drawings and save them based on the name entered in the "File Name" field.
And that's it. It's simple, straight forward, and doesn't try to be clever.
Design Good Systems For Handling User Data
Data is everywhere. It's on the front end. It's in the database. It's everywhere in between. Funny enough, designing a system for getting data from point A to point B is just as much of an art as laying out Bootstrap elements and graphics. Here's my take on dealing with data for this project.
The front end for making and logging in users is all Ajax and JQuery. It communicates user id and passwords over plain HTTP using basic authentication. The back end is done in Flask with an extension called Flask-Login. Passwords are stored and matched using a SHA1 hasher. Verifying those encrypted passwords ends up looking like this.Basic authentication on the client side also must be dealt with by the API on the server side. That helps in managing user-specific data. This setup was somewhat inspired by Github's API. It's simplicity is reflected in the fact that the Requests library uses that API as an example in it's documentation. Flask makes it easy to follow Github's example. Take saving a drawing for instance.
Loading and saving the drawing data was interesting in and of itself. The SVG is XML embedded within the DOMhierarchy. That XML gets converted to and from JSON. SVG.js was used to create the svg data that make up the image on the canvas. On the server side, the data relationships were such that they played very nicely with the SQLAlchemy take on ORM mappings.
Be Critical Of Your Own Work
A critical eye matters, especially for one's own creative works. Here are some issues about this project that make it less than perfect.
Security Problems
Security features are lacking in this project. There are no rules for passwords. Password encryption doesn't use salts. My ignorance on which hasher algorithm fits the bill probably matters. Understanding of Flask-Login is hampered by docs that partly depend on already knowing WTForms. Lastly, usage of HTTP for the api is a less secure communication channel than HTTPS would be. This project is not something that belongs on a public facing production server.
Data Communication Ineffeciency
It also probably isn't the most efficient data setup in the world. It only takes a few minutes of doodling to generate tens of thousands of data records. That means huge data payloads every time a load or save happens. This strikes me as impractical.
Security Problems
Security features are lacking in this project. There are no rules for passwords. Password encryption doesn't use salts. My ignorance on which hasher algorithm fits the bill probably matters. Understanding of Flask-Login is hampered by docs that partly depend on already knowing WTForms. Lastly, usage of HTTP for the api is a less secure communication channel than HTTPS would be. This project is not something that belongs on a public facing production server.
Data Communication Ineffeciency
It also probably isn't the most efficient data setup in the world. It only takes a few minutes of doodling to generate tens of thousands of data records. That means huge data payloads every time a load or save happens. This strikes me as impractical.
Making Things Is Its Own Reward
All that being said, I had fun with this. It isn't useful but it's not really trying to be. Bored programmer has some stupid fun with a project and shares it with the world. Worth it. Everybody should do this.
