Folio Forge
A web application for DIY notebook makers
December 08, 2020
Latest update
This project has now called Folio Forge and is in current development.
Concept Overview
Whom is it for?
- Heavy users of notebooks
- DIY-ers: Those who would rather make than buy notebooks, who find enjoyment or interest in making notebooks, or prefer using home equipment and materials
- Customizers: Those who have a particular requirement and are willing to make tweaks to get there
I write more about the target beneficiaries and their domain in this post: Notebook Builder — Initial Thoughts.
Why in this portfolio?
Because I cannot speak freely about the projects I do for work, including this project was meant to demonstrate my design process, translating raw use cases and core capabilities into a proper user interface.
Note: the project is more heavily weighted toward the design part of the process than user research.
Starting Point
The practice of starting with a raw, core technical capability is a common situation I encounter at work. Often, another team of engineers develops a piece of hardware or an algorithm with its own list of requirements and capabilities that evolved from its own line of user and stakeholder feedback. My challenge as a user experience designer was then to translate a collection of sundry commands into an interface that could provide usable and intuitive access to those raw capabilities.
I typically make a table like the one shown below when assessing the system’s raw technical capability. In this particular case of notebook building, these would be the options or parameters we would want to expose to the user.
| Parameter | Description | Possible Values |
|---|---|---|
| Sheet Size | How big is the paper to be printed on | Letter, A4 |
| Binding Mode | How are the pages to be put together? This will have implications on which numbering algorithm is used | Disc, Signature |
| Pages per Sheet | How many notebook pages to print onto one printed sheet | 1, 2 |
| Page Orientation | Whether the notebook page should appear as portrait or landscape in the final product. | Portrait, Landscape |
| Binding Edge | Where the binding edge should appear in relation to the notebook page | Top, Side |
| Pattern Options | On each page, what pattern to print | None, Line, Grid for 2D design, Grid for Writing, Grid for Isometric Sketching, Ruled, Graph |
| Color Options | What color to print the pattern | Black, Blue, Red |
| Page Numbers | Whether to show page numbers or not (if to show, then how often, whether on each page or one per spread) | Number Page, Number Spread, Hide Number |
Eating My Own Dog Food
Research Method
Notebook Version 1
The first notebook resulted from just settling into the idea of actually binding my own sketchbook and my first try at Coptic stitch.
As you can see, page numbers were an afterthought. I’m also using plain paper, with no printed pattern.
Notebook Version 2
The next iteration featured a print pattern I re-created after a sketch notebook I liked. It turned out to be non-trivial and involve a lot of dirty coding practices.
Printing the page numbers was still to be implemented.
Notebook Version 3
We’re now able to calculate page numbers with a print pattern. Many more iterations were spent trying to get the printer to output a stack of papers that could readily be folded into the signatures.
I also discover the importance of having flyleaves. But this further complicates the algorithm for calculating page numbers!
Notebook Version 4 (Current)
The current iteration comes after exploring cleaner layouts and styling, mimicking the high-end notebooks I observed. Also, I begin experimenting with different patterns and pattern colors.
Starting from early in the process, I had also implemented an “engineering UI” built with Storybook JS. This would embody all the core functionality and expose all the parameters. This was to let me begin prototyping and experimenting with customizing notebooks for my personal daily use and insight. I ran some experiments to observe the process of creating a notebook with an everyday printer and paper. The iterations I went through (below) helped me understand 1) the more important things about making notebooks and 2) how to down-scope my list of feature ideas to a critical set.
This article documents my findings and shows the latest iteration.
Workflow
Synthesis
- Choose notebook size
- Choose notebook binding and orientation
- Choose source paper size
- Choose pattern
- Choose pattern color
- Decide page number setting
- Preview in browser
- Set up browser
- Print Test Sample
- Fold or cut pages
- Bind text block
- Cover decoration, etc
Set up notebook
This phase includes setting the same “specs” used to describe notebooks at a high level: how large it is and how many pages. In the user’s experience, these factors will affect how the notebook is carried around or stored. The system should also consider the materials and techniques the notebook maker will have at their disposal.
Design Challenge: The user is likely to be at risk of parameter confusion, specifying which gets fiddly very quickly. The notebook itself can have a certain size and be either portrait or landscape. Additionally, the paper used can have its own orientation when it’s printed. On top of that, the paper could be cut or folded in half! Differentiating the size and orientation of the notebook from that of the source paper is likely to be confusing.
Sources of Inspiration
- Observing several Bullet Journal Facebook group members ask each other for notebook recommendations and talk about the notebooks they love. Also, many journalers had their “go-to” sizes that they stuck with.
- I found the same information being presented (size, number of pages) while looking through various notebook manufacturers’ websites.
- Having a notebook in a certain unusual shape or page-flip orientation can be highlighted as part of its marketing, such as this Kraft Writersblok Keyboard Notebook, which can sit on a desk alongside a keyboard.
Set up paper
The print pattern depends heavily on the intended use and has a high impact on the user experience, whether the writing, sketching, or drawing.
Design Challenge: Providing the user just enough structure, while without being too confining, in customization.
Sources of Inspiration
- The dot grid pitch of various notebook manufacturers
- Various patterns of paper on the Internet that focus on creative endeavors: writing, bullet-journalling, and planning (ruled, dot grid), sketching interfaces (2D design grid), isometric drawing (isometric grid), other sketches (blank). A graph pattern was also put in for good measure.
- A red-colored print pattern is highlighted in Leuchtturm1917’s marketing of a special edition notebook.
- For artists wanting to digitize their ink sketches, having the color of an underlying print pattern be distinct from the color of pen ink (for example, black ink on a cyan-colored grid) can help with its digital removal after scanning.
Print
This step involves previewing the final result digitally before committing physical resources.
Design Challenge: As (too) many know, translation from pixels to print is not perfect. How might we allow the user to try before committing to allocate print resources?
Additionally, the user’s browser has to be set up just right to produce the result. How might we improve that experience and allow them to get it right with minimal tries? How might we enable a good experience across many browsers, operating systems, and printers?
Assemble
This step of the workflow is entirely within the physical world, and as such, is not within the immediate scope of the web application. However, I’ve included it here because it still has implications for the design.
Design Challenge: Specifically, how might we expeditiously transition the user beyond the digital to focus on the assembly process?
I synthesized my observations during dogfooding and researched how notebooks are described in the marketplace. The following workflow is what I came up with:
| 1. Set up notebook | 2. Set up paper | 3. Print | 4. Assemble | |
|---|---|---|---|---|
| Goal | Establish basic or external “specs” of a notebook | Establish internal look of the paper | Produce all pages (text block) | Put raw materials together into final notebook |
| Tasks |
Below are the same workflow stages in more detail:
Design Principles
Synthesis
Enable Customization
The degree of usable customizability is one of the fundamental value propositions to this app.
One implication of this level of customization is that we’ll need to deliver customized instructions depending on their browser and printer capabilities.
Help the user visualize
The design should help visualize the consequence of the user’s selections to help them maintain the vision of the result. The design should give the user immediate feedback after she makes a choice, such as when selecting a page orientation or the color of the print pattern.
First Iteration
Design
Choosing notebook size and orientation
In this design iteration, I tried to focus on allowing for "direct manipulation" of the notebook. Controls for notebook size, orientation are shown very close to the notebook. You'll see a different approach I took in the next iteration. Section Settings
Oops! Trying to design a mechanism for specifying one pattern per section of the notebook was an unnecessary complication. This approach was later abandoned for something simpler and closer to the core concept. Print Preview
The first iteration explored layout, providing easy access to controls, and helping the user maintain visualization of the effect of adjusting the controls.
One particular feature let the user define several sections within a single notebook and assign a separate pattern to each. I had thought it might be interesting to offer this as a distinguishing capability since I didn’t see anyone else offering this level of “customizability” to their notebook. Spoiler alert: It wasn’t until I made a notebook with different types of filler that I realized it was a bad idea. See the second iteration for details.
Second Iteration
Design
Notebook Settings
Main screen
The new main screen takes on a different approach to organizing the controls than Iteration 1. You'll also see many new features added from insight through "dogfooding", such as an option to print page numbers and showing the number of required printer sheets 
Choosing notebook size and orientation
This gallery approach with a filter seemed to be more usable because recognition is cognitively easier than recall. Animated walkthrough: Choosing notebook size and orientation
Page Settings
Choosing a print pattern
This dialog reuses the same pattern as the notebook size dialog, such as the filtering mechanism and the toggling of different color options, so the user has less to learn. It also includes an ability to print a sample swatch of all the patterns, to help the user decide which is most suitable for their situation. Animated walkthrough: Choosing a print pattern
Print Preview
Compared to the previous iteration, I added a bit more fidelity to which types of help to give the user. I also hint at the ability to “Print Detailed Instructions”, and “Print a Test Run”, which seemed they would be valuable from my “dogfooding”. Still a way to go, however. Without user testing, it will be difficult to predict where people get stuck battling with printer issues.
I abandoned the last iteration because it was overly focused on adding sections to a notebook, a feature that I discovered should not have been in the core set of features.
With the wrong feature out of the way, I could then focus more on the design’s core. The second iteration felt more resonant with what the app needed to be.
One of the breakthroughs for this iteration was realizing just how visual the selection process could (and should) be. This is related to the principle of favoring “recognition” over “recall.”
| Iteration 1 | Iteration 2 | |
|---|---|---|
| Approach | Letting the user fiddle around with settings. Be sure to let the user clearly see the result from changing settings and tweak it until they are satisfied. | The gallery approach lets the user look through the number of possibilities and pick the best one. |
| Result | Too fiddly | Felt much better * |
Lesson learned #1: having the wrong feature considered as the core functionality is costly! Luckily, not as costly as coding up the wrong feature.
Lesson learned #2: If no one is doing a particular thing, there could be an excellent reason, which should not be ignored.
Next Steps
This is still a work in progress
- Gather more feedback on current designs from potential users and other designers.
- Implement and launch the site beta.
- Post link to forums for feedback.