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 .webm 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 #lang web-server.

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

There are three main styles of imageboards2: the Pinterest style, focusing on discovery3; the *chan style, focusing on (anonymous) discussion; and the *booru style, focusing on tagging and searching.

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

  1. *booru style: Hydrus and Danbooru

    hydrus.png danbooru.png

  2. *chan style: 4channel and bunkerchan

    4channel.png bunkerchan.png

2.2 DONE Mood Board & Design Influence

brutalist1.png brutalist2.png brutalist3.png

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
  • SQLite
  • Images
    • Metadata
    • Resizing (for thumbnails)
  • Videos
    • Metadata
    • Thumbnails

2.4.2 Search Engines/Databases

  1. Xapian
    • Not super great language support, see below
  2. SQLite
    • FTS5 adds full-text search functionality to a SQLite database
    • Great language support

2.4.3 Language Candidates

Warning, this section is written with no logic, 100% emotion.

  1. Elixir
    • Possible, but too much overhead for my use-case
    • I don’t want to learn a whole new language for this project
  2. Common Lisp (SBCL)
    • [X] Mature, the oldest of the bunch
    • [X] Emacs (see SLIME and SLY)
    • [X] SQLite (see cl-sqlite or cl-dbi)
    • [ ] Images?
    • [ ] Video?
  3. Racket
  4. Clojure (Winner)

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
    • <tab> accessible
    • Relevant alt attributes 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

  1. Accessible; see above
  2. Tag-based image search; the main feature, no explanation required
  3. 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
  4. Implemented as a web server; allows for the opportunity to be hosted and viewed on mobile (without a complete rewrite)
  5. Notes and titles; ability to add searchable titles and notes to images
  6. 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
  7. Duplicate image removal based on hash; would not be super slow while being immensely helpful for large libraries
  8. 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)
  9. Dark/custom theme option; giving users more choice, make it riceable
  10. “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

scan1.png scan2.png

3.3.2 DONE Detailed Concept Design

  1. Concept 1

    With placeholder images concept1.png

    With some real images concept1-with-images.png

  2. Concept 2

    Desktop concept2.png

    Mobile concept2-mobile.png

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 @media query 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 @media query).

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

Personal opinions

  • 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!

prototype1.png prototype1-import.png prototype1-bulk.png

3.5 DONE Potential User Response

  • It is mad slow, for two main reasons:
    1. Loading every single image in the entire database into the DOM makes scrolling painfully slow
    2. 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!
    • JavaScript slows everything down
  • 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)

4 Product

4.1 Completed Product

4.2 Implementation vs Specification Evaluation

4.3 Personal Evaluation

4.4 Testing

4.5 Customer Views

4.6 Industrial Production

4.7 Summary of Findings

4.8 Modifications to the Product

5 Bibliography

Footnotes:

1

Fun fact: emoticons trace their roots through these textboards

2

In decreasing levels of cultural significance

3

Through an infinite scrolling mechanic