A very in-depth look at Day One 2.0

I’ve been a fan of Day One for quite some time, and Day One 2.0 just came out. It’s a great update, worth every penny, but it lacks some polish that I’ve come to expect from Bloom, given how well the last version was in the last two years that I’ve used it.

The update really nails some key features. Importing from Day One Classic is a snap — the import process on iOS and Mac is fluid and fast, and it requires no extra interaction for people who are already on Day One Sync. A common pitfall that most import tools run into is duplication — running two imports generally duplicates all data that the first one did, but Day One intelligently only syncs data that is missing on the server. This means that the ideal upgrade workflow is just installing Day One and importing the entire database on all devices. Any entries that somehow weren’t synced properly will sync, and anything that already exists in the database won’t be duplicated. Account information is also seamlessly transferred from Classic to 2 during the import process, which removes the need to sign into Day One Sync on every device again.

On the internal storage level, Day One 2 uses an SQLite database to house its entries. Photos are stored in an external folder, outside the database. Classic stored data in a collection of ‘.doentry’ packages that housed an XML entry and a photo. This is the technical reason as to why iCloud and Dropbox sync are no longer possible — the internal data structure is a single file that Dropbox and iCloud can no longer automatically reconcile differences with. As a result of this change, Day One 2 entries are less likely to be duplicated, and less likely to be harmed during filesystem changes compared to the previous model, assuming Day One Sync is doing its job properly.

Day One’s new SQLite database

The relative usefulness of Day One 2 is pretty much identical to its predecessor. Multiple photos and journals are pretty much the only new functionality included, aside from some view parity across Mac and iOS. iOS gains the map view from Mac OS, whereas Mac OS gains the photos view from iOS. When using Day One, I frequently find myself wanting the tag system and search system to be far more robust than it is. With the new map view feature parity, it’s now possible to filter on a specific visible region, but this is about as strong as filtering can get. It’s not possible to only filter by entries containing both tag X and tag Y. It’s only possible to search for tag X or tag Y. It’s now possible to bulk select entries and tag them, which is a nice improvement, but the jury is still out on tag renaming and more in depth tag management.

Can’t bulk rename Tags currently. But we plan to make tag management more advanced and allow this. —@dayoneapp, March 2013

 Mac OS X

Looking more in depth in the design of both the iOS and Mac apps, significant changes were made. The Mac app now “supports multiple windows” and comes with a dual-pane view. Supporting multiple windows sounds great, but the implementation is fairly poor by comparison to what it implies. In order to help describe this functionality, I’ve included a feature reveal image from the Day One 2 announcement blog post.

Multiple Windows?

Making multiple windows is possible, but they aren’t linked in any useful manner. It isn’t possible to have a disconnected “entry only” view, akin to the right-hand side of the dual-pane. The sensible implementation would have been to allow the dual-pane to split into two windows, where the left window is always a timeline view, and the right window is always an entry preview, but this feature simply doesn’t exist. Entries can’t default to being created in a new window, and the only way to spawn a new window is to find an entry, right-click, and open it in a new window. At this point, this window is just an identical window with the dual-pane bar disabled. You can even go back to the timeline in the second window, and enable dual-pane on both windows for seemingly no reason.

The dual-pane view does nothing but anger me. When writing a new entry, I tend to like a lot of space on either side as a “distraction free” writing mode. For this, I disable dual-pane so that the timeline view doesn’t act as a distraction. However, disabling dual-pane resizes the window into “skinny mode” or whatever size the timeline view was split into. At this point, I resize the window back to a somewhat full editing size so I can continue working, and finish my entry. When I push the dual-pane button again, the window now doubles in size, because the left pane becomes the size of the window, and the right side is added back with all of the space it had before I turned dual-pane off. Hilariously, this almost always causes the entry preview pane to fly off the right-hand side of my monitor, because I tend to like my journal entries a certain width for reading. I have to resize the left pane to back into something reasonable for selecting entries, and move the window back into place so that it’s no longer off the screen.

A minor nitpick, that that I’m not sure where to put anywhere else, is the lack of hover-over previews on the calendar view. In Classic, hovering over a date would present a snippet of entries from that day. This simply doesn’t exist in the new version.

Performance on the Mac just seems very non-existent. With 1,300+ entries in now two journals, the UI is slow to respond. Typing feels delayed — as if the rendering system is doing something in the background that prevents keys from responding quickly. Pavel Fatin has an excellent post called Typing with pleasure about typing latency and how it affects brain feedback. Using Pavel’s app Typometer, I benchmarked Day One 2, TextEdit, Sublime Text 3, and iA Writer, for a fair comparison of different applications on OS X to validate my feelings. I ran with OS X 10.11 El Capitan, and I didn’t disable any UI effects. This leads to higher average millisecond response times in the benchmark versus what Pavel gets, but is representative of an average OS X user. I ran the benchmark on a Mid-2013 Macbook Air.

Screen Shot 2016-02-07 at 1.12.42 AM.png

I couldn’t run Typometer on Day One Classic, because Classic has a sidebar that cannot be hidden. The first two graphs are 70 character tests between TextEdit, Sublime Text 3, and Day One 2.0. Day One had spellcheck enabled, no grammar corrections, and smart dashes disabled. In the line graphs, the y-axis is response time in milliseconds, and the x-axis shows which character Typometer was on (Typometer types dots). In the histograms, the y-axis is frequency of response times, and the x-axis is the response time bins. Typometer was run with a 150ms delay between characters, and it waited until the previous character was typed before continuing to the next one.

TextEdit Trial 3 VS Sublime Text Trial 3 VS Day One Trial 3.png
TextEdit Trial 3 VS Sublime Text Trial 3 VS Day One Trial 3 Distribution.png

Because of limitations with Typometer, I was only able to collect 25 character samples of iA Writer. These graphs show just iA Writer, with spellcheck in the same configuration as Day One. This is important to show, because while it’s harder to compare smaller data sets, iA Writer consistently performs better, even with “fancier” features like spell check enabled.

iA Writer Trials.png
iA Writer Trial Distribution.png

The final sets of graphs show all three of the 70 character trials for each application.

TextEdit Only.png
TextEdit Only Distribution.png
Sublime Text Only.png
Sublime Text Distribution.png
Day One Only.png
Day One Only Distribution.png

Of the tested text editors, only Day One exhibits spikes well above 40ms regularly. Day One is also the only editor that regularly spikes high in response time and back down, creating a pattern. Day One’s trials consistently have very high standard deviations. This is indicative of a background task or something being scheduled to continuously kick off, or some other odd behavior causing Day One to significantly slow down at regular intervals. iA Writer was able to perform much better than Day One, with all of the text editing related functionality in the same configuration.

 iOS

On iOS, the design has been refined a lot from Classic. It sports brighter colors, a new set of bottom controls on the timeline, and more. 3D touch support is a no-brainer, and it really makes using the app a lot more enjoyable. However, 3D touch support is inconsistent. It works on the main timeline view and the photo view, but not the calendar view. 3D touch depends a lot on it being consistent in behavior across all apps and all views. For 3D touch to work on the timeline but not the calendar view — despite both having timelines that show small entry previews — this is a big annoyance. It means that I no longer have faith that 3D touch will work 100% of the time, which makes me use it 0% of the time.

Day One Classic followed the UI design pattern that swiping left to right would go back in the view hierarchy. Swiping up or down would scroll through entries. This made sense from the perspective that long entries could be scrolled to the bottom, and then additional scrolling would go to the next entry. In 2.0, this behavior is reversed — to exit the “entry” view and go back to the timeline, a swipe from the top of the screen down is needed. Swiping left and right scrolls through entries, but the buttons at the bottom are still up and down arrows. This set of changes is irritating for several reasons, but the biggest one is that iOS has become more, not less gesture dependent in newer versions. The “swipe left to right go back” pattern is present in so many apps (Safari and Tweetbot are the two I use most often) that I fail to understand why this was changed. The buttons are still up and down arrows, but they now navigate left and right based on the gesture system. Why?

Both the iOS and Mac app suffer from similar problems with photo viewing. On Mac, it’s simply not possible to fullscreen a photo or open it in preview without using the “show in finder” context menu item. Double clicking doesn’t work, and there’s no longer a dedicated button for it, as there was in Classic. On iOS, viewing a photo in fullscreen is possible, but for no good reason, Day One provides a metadata panel at the bottom of the photo that obscures it partially.

Performance on iOS is snappy and efficient, barring local storage space isn’t low. If local storage space is low, Day One turns into a nightmare. I own a 16GB iPhone 6S, and with ≈500mb free, Day One would freeze every few words while typing a journal entry. I only had the hint that storage space was the problem, because during the import process I was told that system storage space was running low. I deleted Classic, but I had to move some photos off with Google Photos (moving free space to ≈2.2gb) before Day One 2 was snappy. Day One acknowledged this is a problem, but gave no timetable on how long it would take to fix.

Yeah, we are aware of this and have ideas and plans on optimizing the local storage. —@dayoneapp, February 2016

Almost all of the problems I’ve mentioned here are the result of the 2.0 rewrite, and that’s just what it is — a full-on rewrite as opposed to an update.

To support Day One 2’s new features, we ultimately rebuilt the app from the ground up, all the while staying true to Day One’s original simplicity. Rebuilding an app as seasoned as Day One is no small task. What I’d hoped would be a year-long effort has taken twice that… but we feel it’s been worth the wait. — Paul Mayne, January 2016

My frustration with Day One 2 stems from inconsistencies. User interfaces work best when they’re consistent inside the app, and across platforms. Full-screen photos should work on all platforms. 3D touch should work in all iOS views. Typing should be snappy on both platforms, regardless of storage space or other background jobs. I definitely feel like these problems could have been identified with more in-depth beta testing and more polish on release. Day One 2.0 was originally slated for release in late 2015, but was pushed to February for what I can only assume was polishing and bug fixing. I’d say that if these issues were identified during testing and not fixed, Bloom should have delayed it until they were.

Day One 2 doesn’t lose data and doesn’t crash, but it’s inconsistent, sometimes slow, and feels rushed. I love it, and I use it1, but I wish that it was in beta a little longer than it was. Day One 2.0 is an excellent “1.0 release” of the rewrite, but it definitely needs some tuning to get back to where Classic is in functionality and consistency. With the price of the Mac app, the typing latency really is unacceptable, but is certainly fixable.

Update (September 18, 2016): I’ve moved back to Day One Classic. The mobile app improved significantly, but it felt like the desktop app didn’t get enough love for my taste. I’m living in a fragmented world right now, with most of my journal sitting in Day One 2, and a new journal in Classic. Data encryption still hasn’t been released for 2, and that’s a bit annoying. Zach Holman never switched, which is food for thought too.


  1. The longest entries I’ve written in 2.0 sparked this review. It’s hard to pinpoint problems with text editors and input latency, and honestly, this is a really big deal breaker for me. I just want it fixed, but until then, I’m gritting my teeth and holding out for a hotfix to resolve these issues. 

 
30
Kudos
 
30
Kudos

Now read this

IPv6 and DOCSIS 2.0 Performance Degredation

Note: This post is exceedingly technical in nature. For those experiencing similar problems, skip directly to the fix. The Problem After coming home during break from university, one of my first objectives was to replace a dying wireless... Continue →