Zotero 6: A Review | Hendrik Erz

Zotero 6: A Review

Zotero 6 is out — time for a review. I tested the app in production for two weeks now and want to share my thoughts.


After what feels like years of development, the Zotero team released the next iteration of the best reference manager out there to the public in March. I immediately updated my install and gave it a try. And I must say: I’m very satisfied with what they deliver.

In this article, I want to just give a quick review of what improved and give my general feedback. Additionally, I want to highlight one instance where the team accidentally break a lot of workflows unintendedly, which resulted in a small dispute with the Zotero team.

After I gave the new built in PDF reader a try, I discovered that my annotations were not stored in the file and complained about that on Twitter in what a colleague of mine quickly pointed out was a way too toxic and snarky tone:

Therefore, before actually diving in, I’d like to issue a formal apology to the Zotero team for my language on Twitter and would like to reaffirm that I am still a fierce supporter of the app. My review from last year still holds true: Zotero is the best reference manager out there.

But now, without further ado, let’s dive in.

The New Look

When I opened up the new Zotero I looked around and found out that nothing much has changed with the interface. And that is a very good thing!

When more and more people use an app, you want to gradually transition your user interface to a new look instead of breaking things everywhere. What you will notice if you’ve used Zotero before is that they changed the overall design and adapted it to look much better. They’ve increased the spacing in the main view ever so slightly, which makes the app now look much more modern.

Furthermore, many interactions have become smoother and easier to perform, which makes the workflow with the app easier. And I bet that below the surface many more things have changed for the better, since the app itself also feels more snappy now.

In short, they managed to overhaul the whole app without breaking any habits we might have developed for the better or worse.

Did it Break?

Another good thing that plays into the whole notion of “never change a running system” is that they retained all plugin functionality. I was very pleased to see that BetterBibTex and ZotFile just continued working as if nothing ever happened.

This shows that the team was keen on improving Zotero without alienating existing users, and I think they managed to pull that off quite easily. Even the Zettlr integration with Zotero didn't break, everything just works out of the box.

Overall, I am very pleased with Zotero 6 and how they improved it. But I announced that I have something to complain, and that has to do with the long awaited new feature: The built in PDF reader. So let’s get to that next.

The PDF Reader

The possibly most longed for feature is the new built in PDF reader. By default Zotero will now open PDF files in a new tab within Zotero in its new PDF reader instead of whatever app is installed on your system.

You can always change the setting in the preferences so if you prefer another reader, it is very easy to restore the old behavior. But especially for Windows, where good PDF readers are hard to find, I am sure that this is a real and solid improvement, and I will for sure make use of this built in PDF reader a lot when I’m working on my Windows machines.

On my macOS computers, however, I will at least for the time being stick to PDF Expert, which is still much better than the built in reader. This shouldn’t come as a surprise, because building such a complex feature from the ground up is prone to take time, and I can’t wait to see how they improve the reader going forward.

Nevertheless, I obviously gave the built in PDF reader a try. It looks extremely clean and minimalist. Since the use case for that PDF reader is much narrower than, for example, for a general reader such as PDF Expert, the Zotero developers could keep the toolbars very minimalist and only offer the most valuable tools: Highlighting and commenting.

Using these is very convenient and I must say I’m pleased with what they came up with. The annotations themselves work very smooth even with some of those abysmal scanned-after-the-fact PDFs which just scream “kill my OCR and redo it!”

In order to fully test out this feature I used Zotero to annotate one of the PDFs I have on my bucket list for a course I’m taking at the moment. The next day, I navigated to the PDF, opened it and … my annotations were gone?!

This is where we come to something bad the Zotero team has done: A form of vendor lock-in.

Raiders of the Lost Annotations

I immediately suspected that the annotations were maybe stored only within the Zotero database, so I went back to Zotero, opened the PDF there and, indeed: there were my annotations.

This discovery led to my angry tweet above (sorry again, Zotero!!) and to subsequent thoughts on what happened there and why I think my point is still valid, even though my language was not.

For ever since PDF has been introduced, we have gotten used to store our annotations in the PDF file. This is a good thing: Those annotations “belong” to the document, and therefore to store them right with the original document is just the sensible way to go.

Furthermore, because this is such a strong institution (as in: Powell’s and DiMaggio’s institutionalism) many workflows implicitly rely on that fact, and oftentimes you can only see your implicit assumptions once they are violated.

My workflows involve frequent moving around of PDF files if I need them someplace else. I oftentimes open my PDFs on my tablet or even in my browser (I sync them via a custom Nextcloud instance), which comes in very handy if I’m at a colleague’s computer and want to show them something. If the annotations, however, are not contained in the file anymore, it is harder for me to navigate the file.

I have a photographic memory, so I can tell you precisely what’s written at certain points in a document based on its actual location (which is why I’m struggling a lot with eBooks). If those annotations are now only visible when I open the PDF with a specific method (Zotero in this case), this constitutes a form of vendor lock-in. And vendor lock-in is bad in every respect.

Vendor lock-in describes the practice of software to lock the contents of something to a specific form, or presentation. PDF, for example, is also a form of vendor lock-in, albeit a very mild one because we can read and write PDF files from a plethora of programs, so it doesn’t feel like a lock-in. But always remember: PDF is a proprietary format owned by Adobe.

When Zotero now stores the annotations in its own internal database, it performs such a form of vendor lock-in itself. In order for you to be able to utilize your annotations, you are required to open the PDF file in Zotero. You cannot simply open the PDF file with any program anymore.

It is very important at this point to emphasize that this has nothing to do with malicious intent or anything. And I believe the rationale is a very good one. It just came … unexpected.

Why Would You Tear Apart Annotations From the PDF?

This leads to the question why do this in the first place? The reason is that it’s much simpler to synchronize collaborative annotating when you only store the annotations.1 PDF files are very easy to break, so if you want to enable multiple persons to be able to view those highlights and edit them, it is much easier to do this if you do not write the annotations to the actual PDF file.

So for collaborative settings this is a very clever and good move. This way you can much easier talk about certain parts in files because every participant (of a group library, for example) can see the same set of annotations. This makes communication much easier.

However, if you mostly work alone on your files (as most researchers in the humanities do), you don’t need collaborative editing. And therefore it will suddenly feel as locking you in, because you expect your PDF files to be kind of the “source of truth” in your workflows, not your reference manager.

Of course, Zotero is an open source app committed to not doing that, so you can simply write those annotations from the internal database into the PDF file.

… or, can you?

Breaking Your Expectations

I would describe myself as a person who is very apt in using computers and software, but I really struggled to get the annotations out of the Zotero database into my PDF file.

A user thankfully told me how to do it:

You can write them to the file. File > Store Annotations in File. This will convert them to regular PDF annotations. The big downside is that you can't do this automatically (yet?). You have to go to the menu every time and click the little "Are you sure?" box.

Alright, easy. So just open the File menu and … nothing.

After what felt like an eternity, I finally figured out what was going on: Zotero changed the contents of the File menu depending on the tab that was highlighted in the app.

And that’s a very evil thing to do. Again, let me reaffirm that none of this is intentional. It is just a UX accident that could have just as easily happened to me. I am by no means immune from that. But it nevertheless breaks expectations in a very bad way.

On Windows and some Linux window managers, a menu is bound to a menu bar on the window itself. So you expect that the menu stays the same for that window. On macOS and other Linux window managers, the menu bar is moved to a bar at the very top of your screen, so it is detached from your window. In these cases, you expect that menu to always stay the same (although it is reasonable to have that menu change depending on which window the user has focused).

So what you expect with regard to the menu is that it will stay the same for the current window, and only change (if at all) when you click on a different window.

However, the Zotero team faced the problem that the PDF reader requires a completely different set of menu items than the main view. And because all of that happened in a tabbed interface, and not in separate windows, one should not expect users to notice that the contents of the File menu have suddenly changed behind the scenes.

One would definitely notice if the label of the File menu changed, for example from File to PDF File. But by not changing the label, it is impossible to notice that the menu now has different menu items in it.

I cannot remember an app that did that, and therefore it’s very bad to do that. I strongly believe that this is a limitation in the framework Zotero is using, so it’s likely more the fault of the framework than the Zotero team, but it’s nevertheless bad.

One could’ve gotten around that by either intermingling all menu items, and simply disable those that aren’t used for the view you are looking at. This way, I would’ve spotted the (greyed out) item to store my annotations in the PDF file, and then it would’ve been easier mentally to come to the conclusion that one maybe needs to focus the PDF file to do so.

But let us assume that this was no option and exchanging the contents of the menu was without any alternative. Then what Zotero could’ve done would’ve been to provide a toolbar button that one could use. Because the toolbar was the first place I searched. The second place was the context menu of the PDF file. But I didn’t think they would silently exchange a full menu.

Annotations as a Two-Way Process

But what then might be a better way to do all of this? I clearly see the benefits of the way they do it currently, and this might even become a more common way – to separate annotations from the physical contents. However, I think we’re not quite there yet.

Most people will expect the annotations to be stored in the file, so what might help would be to think of this as a two-way process. Specifically that you have two buttons, one which extracts the annotations from a PDF file into Zotero’s internal database, and one which writes those annotations back to the PDF file.

This way, one could convert this process into a conscious one, and every user would have to think about what the source of truth is for their own annotations. If you frequently annotate collaboratively, then you would basically always want to sync the annotations from Zotero to your PDF file. And if you work more on your own, you would basically always want to sync the annotations from your PDF file to Zotero.

This way, everyone would benefit from the new ways to interact with PDF files, and it would also make the transition easier.

But as I said earlier: PDF files are very fragile, so I can understand that this is a delicate process and that you want to make sure nothing breaks. In any case, the new Zotero is awesome and I again recommend to switch to Zotero if you do not already use it.

Conclusion

Overall, I like the new Zotero experience, and I think the team did a great job. The new PDF reader will be a blessing for those who just want an easy way to create annotations, and I think it can certainly deliver. There are of course still a few pain points, but that is to be expected.

I am really looking forward to how the PDF reader experience evolves, and I am certainly willing to change my workflow again to store reading notes maybe completely in Zotero in the future. But for now, I hope they will make the PDF reader accessible to everyone, not just those who exclusively work within Zotero so that we can all benefit from such a great feature.


  1. Marijn Haverbeke, the developer of CodeMirror, has an excellent piece where he goes through some of the problems you will encounter when several people try to edit the same data structure in different places. Recommended read! 

Return to the post list