About two weeks ago, atlas ti web (“cloud”) fatally crashed while I was using it. Frankly, atlas ti is an unstable piece of crap and I want my money back, so I jumpted on the opportunity and got serious with taguette, with a good line as to why I am using an unestablished software for my research. I kept notes on the experience with the intention of filing a few tickets on things that would benefit the user experience, but they got so extensive that I decided to take down my thoughts in this document, too.
Based on performance alone, taguette is off to a very good start. My experience with atlas ti desktop, nvivo, and maxqda is limited, but I have heard my fair share of complaints from colleagues. I tried them all, briefly, and I was not impressed–Dedoose in particular was a disaster. Then again, some of it comes down to the fact that I am a linux user, and I am just not serviced by these companies–sure, I could run a virtual machine, and I did use wine to test some of them. On the other hand, I assume the experience is not much better when you use them natively. The UI, the user experience, it’s clunky.
Where is taguette’s potential niche? I don’t see taguette gaining native support for PDFs any time soon–which I thought would be the killer feature for atlas ti web–so I think taguette should play into it’s strength, which is responsiveness. Seeing as all data requests in taguette are handled through SQL, I think maintaining taguette responsive shouldn’t be too much of an issue–not that SQL requests cannot be messed up by bad coders, so I am assuming some level of competence here.
What should taguette be striving toward? I think the reason why QDA softwares have not caught on more widely–why should only qualitative researchers be using the software, and why only once they reach the data analysis stage?–is that the user experience is not great. I am reminded me of how clunky Mendeley felt when I did anything that it was not intended for (and what it is intended for is really only, only the word plugin). In comparison, once I had set up Zotero, settled on Okular, and had all the plugins set up–it is a piece of software I actually like having open all the time on my second screen just to grab the papers I need. I am not talking about Zotero’s UI, what I hope taguette could do is give you fast, convenient access to your qualitative data and just allow you to focus on your analysis.
To some degree, that kind of user experience for scientific research is about getting out of your way and giving you freedoms. The approach of making your data relatively accessible through an easy to find SQL file–that is also interoperable with other FOSS QDA software–is just right for that purpose. An obvious role model with a similar approach to separating software, UI, and data is jupyter, and I suppose taguette has already learned a thing or two from that project anyways. In my opinion, taguette could never learn enough from jupyter lab–that’s a software I always enjoyed starting up and looking at my data in.
I don’t want to get too much into it, but there is probably a further argument to be made about learning from the jupyter project’s goal of easy iteration, sharing, and collaboration (Shen 2014). Maybe a long-term aspiration could be to assist both the qualitative work itself, to also give users the best means possible to share their results, and to allow collaborators and the audience to retrace if not reproduce the results. I am not quite sure what that would look like. Part of it is the option to output codes and coded document in easily accessible data formats–taguette already has plenty of these options. Another element is probably to enable the slicing and dicing of the qualitative data and codes. A third element would be collaborative coding and checking for intercoder reliability. Taguette is already partway there for that last one–just like I can host jupyter lab for my organization on a server, I can also imagine hosting taguette and giving my collaborators access to that–in fact, I am thinking about adding that to my server right now, it would be a nice supplement to my wiki, which I often use to share notes and early drafts. I have learned R, Python, bash and some SQL over the last four years–it does not seem to unreasonable for me to learn some Java, too, and help make some of that happen eventually.
Below is the list of observation that I created from my notes. Roughly in order of priority. It is an entirely unfiltered list, so there are some pretty miniscule things on there, and some stuff may be inaccurate where I did not double check? The fact that it’s quite a long list does not mean that taguette is inherently flawed–I did really enjoy using it.
- Display the document name above the document.
- Provide an option to search all documents in a project or globally.
- Provide a dedicated scrollbar for the documents in the project (left sidebar) or a different mechanic–I noticed that when wanting to scroll through the documents in a project, I would need to scroll to the bottom of the document first. At first I thought scrolling was broken when I was in a very long document, before I tried using ctrl+end. Makes for an awkward experience with long document+long list of documents–I have to jump to the end of the document first and then scroll up rather than just scrolling down to the document I am looking for. The obvious alternative would be for scrolling to move both content+sidebar together at first until the end of the sidebar is reached. Another one is the current solution for smaller screens–placing the sidebar above the content.
- Document overview page for all the documents in a project–this view could offer features for filtering documents to find exactly what you are looking for, e.g., filter by name.
- Also related to point 3, but admittedly a lot of work: make the two elements–Document list and document contents–independent. When clicking on a document on the list, really only the document contents should be refreshed. That would allow for the users to quickly go through a couple of documents to find what they are looking for. Let’s say I have three documents and I am not sure which one contains the section of interest: currently, the way to find out is to scroll down, click, look at the document, scroll down the document list, click and check again, and repeat one more time.
- Vary colors of highlights–this becomes important when the user tags two successive paragraphs. I think there are a lot of ways for going about this. Either, taguette could progress through some pleasant color palette, back and forth? Or (random?) contrast colors could be used? Or the palette could be linked to the tags. It should be consistent when repeatedly opening a document though.
- In the highlights rider, provide an option to add tags to an existing highlight with tags, e.g., when showing all highlights for one tag. This and te following couple of suggestions are related to the work step of refining and consolidating existing texts in inductive studies.
- Provide an option to combine tags for filtering in the highlight rider.
- Provide an option to merge two tags into one.
- When clicking on the name of a document in the highlight rider, go to that specific highlight in the document after loading the page.
- Automatically jump to the name field when clicking on “Create a tag” in the Highlight window.
- Automatically open the Highlight window when highlighting a section of text–seriously, what else am I going to do?! Joke aside, there would still need to be an option for copying the text, but that is 1 time out of 100 times I highlight a section of text.
- The prior change would render this redundant, but when highlighting a section, the “new highlight” pop-up/button should really appear near the mouse pointer, not at the end of the highlighted section. Scrolling up while highlighting a section sometimes means that the “new highlight” button is out of view at the end.
- Search for tag by name when creating or changing a highlight (rather or in addition than the current checkbox approach)–this could speed up the workflow of tagging significantly. Highlight a section, the window pops up, user starts typing, ideally there would be some kind of autocompletion, meaning I only need to press enter after a few letters and can then start typing the next tag.
- When I create a new tag from the Highlight window, it should automatically be selected (the box ticked).
- Allow for more than one column in Highlight window–not having to scroll through the tags always allows me to have muscle memory pop in as I remember the position of tags. Especially appreciated when using the same tags very often.
- When adding a document, it should probably be opened.
- Drag-and-drop documents in addition to the “Add a document” button.
- Show tags on hovering over the highlight without needing to click on it.
- When the highlighted section ends at the very right of the screen, the highlight button sometimes is partially off the screen. Up to 50% of the button might be covered by the end of the screen–obviously not a serious issue, but still something I noticed
- Provide an option to create a copy of a project with all highlights removed (e.g., to recode or to allow multiple researchers to code a project separately).
- Provide an option to export a project.
- Dark mode.
- An option to sort tags in the highlights rider by recently used–I find when I create a new tag, I tend to forget it after five minutes, and only after I have used it a couple of times do I remember the tag. Would be great to be able to look up the tag I just created, or the tags I used most recently, as opposed to being swarmed by tags i haven’t used in ages.
- Allow for longer file names–my naming system is context-date-time-title(the last one being optional) sometimes when adding a title I go over length. This one is at the very bottom because it’s important
- Sometimes, when opening a document from the highlight rider, the document itself will not open–although the other documents do–and the user has to reopen or reload the page
- This one is really purely a QoL and probably not worth the work, but it would be great for taguette to remember the last position the user was in when closing a document, and for it to return to that section when the document is opened again
- Now, I admit this is just straight up sci-fi. But I dream of a day when taguette uses integration with a pdf reader to handle tagging pdf documents. Zotero does that well–but the task is much easier for Zotero since it is intended for opening documents externally. What I have in mind is something like the old version of Okular which used to save annotations in a separate .xml file.
- I know I am going wildly off-topic now, but I wish taguette stole shamelessly from jupyter labs and that it may become a mashup of all the best features of the established QDA softwares (with none of the performance issues).
Shen, Helen. 2014.
“Interactive Notebooks: Sharing the Code.” Nature 515 (7525): 151–52.
https://doi.org/10.1038/515151a.