Product Design Project
Mirrored from the repository.
1 DONE Context and Objectives
What is your project about?
My project is a personal imageboard following the *booru style.
Why was this project chosen?
This project is something I would personally use because I have
currently a unsorted mess of memes, twitter screenshots and
files that need to be organized.
What do you expect the end result to be?
I think it will probably be a web app with the browser pointing to
localhost. During the set brief I wrote about how I could use
Electron, but there really is no need, as I would not be using the
Electron APIs in any special way.
I am also reconsidering my initial thoughts of using Clojure, and am currently learning towards Racket’s
What do you hope to learn by doing this project?
I hope to learn more about web development in general. I have in the past stuck with the Jamstack, but I want to try to build a “real” server-side application.
How will your project meet the set brief?
It may miss some of the technical choices made during the set brief. Those were not hard requirements, so I don’t feel guilty about changing my mind. Otherwise, the main objective has not changed.
2 DONE Research
2.1 DONE Product Analysis
2.1.1 DONE Primary—Hydrus Network Client
The hydrus network client is a desktop application written for Anonymous and other internet-enthusiasts with large media collections. It organizes your files into an internal database and browses them with tags instead of folders, a little like a booru on your desktop. Tags and files can be anonymously shared through custom servers that any user may run. Everything is free, nothing phones home, and the source code is included with the release. It is developed mostly for Windows, but reasonably functional builds for Linux and OS X are available.
An imageboard is the generalized term for a application (that is in most cases deployed to the www) that focuses on the sharing of images. The term comes out of the textboards popular in Japan, which are simple text-only discussion websites.1
The Hydrus Network Client (Hydrus) is a personal imageboard in the *booru style. This discussion will not focus on the underlying Hydrus Network Server, which is its own can of worms.
It is written in the Python programming language using the Qt GUI library primarily targeting the Windows operating system. It supports all major image formats, a handful of video formats and codecs, some audio codecs and a few other file types too.
When importing images into the software, a copy is made when
importing into the internal database, and the images are given an
inbox tag “just like your email” for easy tagging. Because copies
are made, the original files can be moved, renamed or deleted with no
loss to the database.
One killer feature of Hydrus is the Public Tag Repository (PTR). The PTR allows for images to be automatically tagged with user-contributed tags if the hash matches. These tags must be downloaded along with the hashes; the documentation notes that this download and sync “usually takes a couple of weeks.”
2.1.2 DONE Secondary
- *booru style: Hydrus and Danbooru
- *chan style: 4channel and bunkerchan
2.2 DONE Mood Board & Design Influence
2.3 DONE Anthropometrics & Ergonomics
- Anthropometrics and Ergonomics fit less in a digital project
- It can generally be condensed into the category of Accessibility
- The guidelines on the A11y Project’s Website should be followed
2.4 DONE Materials (Software/Libraries) Analysis
2.4.1 Baseline wants and requirements (see the set brief)
- A mature functional programming language
- Resizing (for thumbnails)
2.4.2 Search Engines/Databases
2.4.3 Language Candidates
Warning, this section is written with no logic, 100% emotion.
2.5 DONE Client (me!)
- Someone who has a large, unwieldy and unsorted collection of images
- More specifically, someone who wants to sort their collection for ease of use
- A tool to search and tag can really help achieve that goal
2.6 DONE Research Analysis; In Summary
- Personal imageboard
- *booru style
- Brutalist inspired design
- Clojure programming language
3 DONE Design
3.1 DONE Design Considerations
- Highly important: accessibility
- Legible text
- High contrast
altattributes for each image
- Dark theme option
- It should be fast, like really fast
- Should “feel” snappy and lightweight
- Not the following (overused, ugly, bloated):
- Material Design
- Twitter Bootstrap
3.2 DONE Design Specification
- Accessible; see above
- Tag-based image search; the main feature, no explanation required
- A copy of images should be made into the “database” (images will probably be in a flat folder, named by hash); allows the original images to be moved, deleted or renamed without issue
- Implemented as a web server; allows for the opportunity to be hosted and viewed on mobile (without a complete rewrite)
- Notes and titles; ability to add searchable titles and notes to images
- Both “behind the scenes” filesystem access and HTTP upload form; bulk initial import could be done on the backend, while incremental additions could be uploaded
- Duplicate image removal based on hash; would not be super slow while being immensely helpful for large libraries
- Portable to multiple operating systems with a focus on GNU/Linux; the backend only needs to run on a server or (rarely) the user’s local machine, and GNU/Linux is the OS of servers (BSD fanboys please don’t kill me)
- Dark/custom theme option; giving users more choice, make it riceable
- “Stretch goals”
- Tesseract OCR integration
- Imageboard (*chan style) thread-watcher
- Geographic map of photographs based on location metadata
3.3 DONE Concept Designs
3.3.1 DONE Base Concept Designs
3.3.2 DONE Detailed Concept Design
3.3.3 DONE Concept Design Evaluation
Which has the best chance of success?
The first design is the best one for desktop usage, while the second
is better for mobile browsers. Combining the two with a
is probably the best way to go. The two designs’ html markup is the
same, so only css styles are going to need to change (again, using a
What problems are there that need to be addressed?
- What the default stylesheet looks like (there will be an option for the user to change themes, see above)
- Settings page (custom themes, image directory, database location)
- Location of other features
- Notes section will go directly above/below the tags list
- Thread watcher/map can be separate tabs next to or below “Dewey”
How does they meet the spec?
- These designs are just that, designs
- There is no underlying functionality, they do not work at all
- Otherwise, assuming I can get it to work with my prototype, the design matches the spec
- Ugh, I hate judging my own work
- The stylesheet is certainly still a work in progress
- I only whipped the whole design together in about a half an hour
- Seeing an actual design has really gotten into a frenzy about
working on this project
- I’m really excited to see the final product now!
3.4 DONE Early Prototype
Here ya go!
3.5 DONE Potential User Response
- It is mad slow, for two main reasons:
- Loading every single image in the entire database into the DOM makes scrolling painfully slow
- Running Tesseract on every image makes importing media painfully slow
3.6 DONE Final Product/Redesign Considerations
- Switching to the *booru tradition of pagination (or even virtualization) probably will speed up the first point above
- Selectively running Tesseract, instead of in bulk might help the second point above
- I also need to add the ability to manually edit the other metadata within each file (notes, OCR text, etc…)
- Embrace server-side rendering, don’t build a fat client!
- Embrace the filesystem, don’t just dump hashes in a folder!
- Having media put in meaningful folders allows for use with phones etc that use folder-based sorting
- Embrace keyboard shortcuts, good for speed and accessibility!
- If an actual grid (instead of a flexbox) is used, it will be much easier to calculate the shortcuts (i.e. go to next row)