- If you want people to use it on the web: do not under any circumstances use the pure-canvas approach. You must use real DOM, or it will be an endless frustration that turns many people away. I’ve written about the problems quite a few times, look through https://hn.algolia.com/?type=comment&query=chrismorgan+pure+... if you’re interested. If you’re not intending it to be used via the web, don’t worry.
But it’s a general principle: the more you are implementing from scratch, the more of a mess you’re likely to be in. As one example, at IME is completely broken, completely preventing a lot of non-English usage. Even my Compose key is broken: the key sequence `Compose - >` should produce →, but instead produces “Compose->”. This is the first time I’ve seen the Compose key turn into the word “Compose”!
For serious desktop-style applications, I honestly recommend that you not use plain-Rust GUI just yet. It is definitely steadily getting there, and I’m very optimistic that there will be at least two reasonable choices available within three years, but it’s still not where I’d want it to be for an app like this yet. Web browsers are, unfortunately, typically the pragmatic choice, even for desktop-only apps.
- It’s a great point. This uses the canvas element only because it’s rendering in the browser. But this is really a desktop application, so the canvas element doesn't come up as a concept outside of WASM. Your main contention seems to be that nobody other than web browser implementers can render and edit text, and thus we should be limited to the set of applications that can run on the DOM and leverage the web browser’s shaping and layout engines.
There are issues solved by the DOM for sure, but it requires shipping an entire web browser, and this product is a dedicated word processor. I’d rather face those issues head-on than defer to someone else’s implementation of such a core aspect. I know IME is broken, and Tritium’s really only able to address the needs of the happy path at the moment, but if can do that well, then there’s a business model to fund solving the edge cases to bring a real Word competitor to the desktop for lawyers.
- > thus we should be limited to the set of applications that can run on the DOM and leverage the web browser’s shaping and layout engines.
Yes, if you want to run in the web browser, use the APIs the browser gives you. If you want to go wild, run directly on desktop OSes.
Web browsers just straight up don't have some of the APIs you will need for a working app. Accessibility is a major example. If you want to stay compliant with legislation (probably something to care about when selling to lawyers), you'll end up poorly re-implementing an inferrior version of your GUI framework as a DOM tree for accessibility.
Sometimes your use case is just so uncommon and esoteric that's genuinely what you need to do (see Google Docs), but keep in mind that it requires Google-like levels of engineering investments to do it at least somewhat well.
- Very true! That's why this is just a "web preview". It's not intended to be used as the primary application. As mentioned elsewhere, the primary application is a desktop application that does look to leverage native APIs that aren't available on the web.
- > Your main contention seems to be that nobody other than web browser implementers can render and edit text,
I took it as a claim that using the canvas you can't implement _inputs_ correctly. The example given was about compose sequences, but I'm sure there's much more to it.
- Yeah the GP’s reply was a little misleading/ambiguous. It begins by saying “great point” but then it distorts & argues against that point.
Better just to disagree directly, I think.
- Maybe u/piker misunderstood u/chrismorgan's point.
- Build it on Makepad, who are building the UI framework (blew me away first time I saw it in action). Leaves you to build the app.
- Makepad is pure-canvas. It’s similarly entirely unsuitable on the web, and probably still not yet great on desktop, though it’s heading in the right direction.
- I for one appreciate the "no html" approach.
That being said, if this is truly a desktop application, why waste time making it run in a browser? If the point is to have a preview, put the time into making some good short videos that can go into a preview page.
- Because it's cool to get your hands on something before diving in. Also it allows users in walled off corporate environments to preview it without having to jump through thousands of hours of infosec hurdles.
- Considering it's just the desktop application being rendered to a canvas, I imagine not a ton of effort even needed to be put in and the UI framework is handling most of it.
- > but it requires shipping an entire web browser
That’s a moot point and completely irrelevant for 99.99% people.
- Perhaps that is an accurate percentage, but lawyers are in that .01%. If you're competing with Microsoft Word on performance you'd better be stupid fast and lightweight. Transactional lawyers routinely have dozens of Word documents and PDFs open at a time. Not long-term viable with something like Electron.
- Word has the worst performance ever. So I don't think competing with Word on performance should be hard.
- Not necessarily. You can have dozens of Word instances open and it still doesn't bog the system down nearly as much as 5 Notions with the Chromium renderer. Word might not seem fast, but it's lightweight enough to work on the crappiest PCs you (or the IT dept) can find.
- VS Code, the aforementioned very performant Electron-based IDE, would like to differ
- VS Code is very much a special case and not the least bit representative of the typical Electron app. It benefits from having some of the best talent available working on it and has multiple bits that drop down to lower-level solutions to improve performance, both of which Microsoft is willing to pay for because VS Code entrenches them in the software development world in ways it wouldn’t be otherwise.
- > has multiple bits that drop down to lower-level solutions to improve performance
Such as?
> VS Code is very much a special case and not the least bit representative of the typical Electron app.
And Obsidian, and Discord, and Logseq, and Notion, and Figma, and Slack, and Postman, and Insomnia, and so on, and so. Oh wait, so it's not only VS Code?
- > Such as?
At minimum it uses ripgrep for file searching, which is written in Rust but I thought I read blog posts about other parts in the past.
> And Obsidian, and Discord, and Logseq, and Notion, and Figma, and Slack, and Postman, and Insomnia, and so on, and so.
Out of the mentions in that list I’ve used, only Obsidian feels comparatively responsive to VS Code. Notion and Slack in particular are slow and can get super bogged down. Discord and Figma sit somewhere in between.
- I'm not sure I agree it's "very performant", but nonetheless I do love it. (Compare it to Zed, for example.)
In any event, VS code is only required to render text in a single font, with very few layout concerns, styling, run-level formatting, etc. that require re-flowing across multiple of pages, etc. And each of those is text files measuring in the bytes. Tritium, by contrast, has to hold and operate on PDFs and Word documents each with very complicated layout and rendering logic and measuring in the kbs.
- People praising VSCode's performance are probably better defined by having too fast computers than anything else, by all measures VSCode really isn't particularly lightweight nor performant.
- It is definitely not as performant as Word on 5+ year old hardware that can barely run Windows 10, that many companies will happily order tons of.
- You do get a lot for free with the DOM, but it's messy, works differently between different browser and you have to constantly fight it. With your own rendering engine it's more work but you have much more freedom and can get better performance.
- With DOM you get accessibility integration. At least in the EU if you provide a web service you have to be accessible, otherwise you can get sued.
- IANAL,afaik the accessibility law is only for government monopoly services. But I don't think it matters, because if you use the DOM you still need to test if the app works in screen readers etc, even normal websites have trouble with accessibility.
- AFAIK it applies to everyone. But you don't get automatically fined, someone has to sue first. Maybe there has to be a business relation between the user and the web site? And yes, with HTML you need to still use all the right tags and attributes to make it accessible. Firefox has a nice accessibility tree view in its dev tools that you can use for debugging. Is there something like that for this toolkit? Is it somehow exposing an accessibility tree? Replicating everything in DOM for accessibility?
- This is explicitly called out in the canvas spec's best practices section with a laundry list of things you'd have to re-implement [1].
> Authors should avoid implementing text editing controls using the canvas element. Doing so has a large number of disadvantages:
> [...]
> This is a huge amount of work, and authors are most strongly encouraged to avoid doing any of it by instead using the input element, the textarea element, or the contenteditable attribute.
[1] https://html.spec.whatwg.org/multipage/canvas.html#best-prac...
- The way this app is architected with Rust and egui, they can write code once and deploy a GPU accelerated app across all major operating systems and the browser, without having to ship a web browser with their application. That's a strong draw for developers. I think it's important to ship products like this, even if some users are frustrated, because that frustration will breed innovation. Since they said it's meant to be desktop only, I think what they're doing is fine, as the web is just an added bonus.
The approach they've taken can create frustration, but it can also be seamless for users and create joy. For instance, I got to try out their app without any setup on my part, and then I can download it and it works exactly the same on my Windows and my Mac machines, because it's the same codebase for all three platforms. That kind of story was the holy grail of UI tooling for many years, and I think we should keep going down that path to improve it, despite frustrations along the way.
- Wait, which 2 do you expect to become usable?
- It might not be particularly visible from outside just yet, but we’ve reached the stage where a lot of the fundamentals (which are typically deplorable in quick-and-dirty libraries) really are being nailed down quite nicely; and, perhaps more importantly, where a lot of the different teams are sharing work and collaborating on libraries, rather than each project starting from scratch. The momentum around AccessKit is the most visible example of this.
The Linebender community is a very promising venue for such collaboration, and there are at least four organisations investing quite a bit into this and related endeavours.
I won’t name any specific two libraries. It also depends a little on whether you’re targeting web tech only, or web and desktop, or desktop. (Or mobile.)
- Feedback: the UI feels like a direct reference to VSCode, which is familiar to software developers, but not to lawyers. If you're hoping this will be adopted by lawyers, I would focus on making the UX familiar to them. Look at software that they already use, and mimic those idioms insomuch as it makes sense to do so. I would also have the base web domain link to a normal home/info page, not to the demo directly. And maybe prefill the demo with some actual content (documents/etc) so people can really see what it does and how
Good luck!
- Great feedback; and I do agree. The HN link goes to the app itself because we're impatient, but there is an actual landing page most visitors hit.
I've gone back and forth on the UX idea, and while I do agree, it's important that Tritium selects for users that are going to be able to quickly adopt the newer concepts. Just simply presenting a "better Word" isn't really going to move the needle. It's really a shift in expectations. That said, I have recently backed off defaulting to dark mode to make it feel slightly more familiar.
- I think software people tend to underestimate the value of superficial familiarity. By all means, adhere to your new concepts and mental model. But even things like coloring, placement of the menu bar, the icons that you use, the organization of the UI, etc can go a really long way
Think about programming languages- ones that introduce radical new concepts may still employ familiar syntax/naming to smooth the transition for newcomers. Rust mimicked C++, TypeScript extended JS, etc. These languages were made to introduce powerful new ways of thinking about code, but by appearing as similar as possible to what devs already knew, they freed up more brain cycles for people trying to adopt them. They didn't muddy their concept-space for the sake of familiarity, but they didn't introduce any more unfamiliarity than they actually needed to for the benefits they wanted to give
- No attorney who is flummoxed by this UX is going to touch an AI product in any meaningful way. Making legal tools for lawyers who would otherwise be using cuneiform tablets or the dictation pool is a waste of conversation. Looking similar to the tools a seventy five year old lawyer uses is like making an F1 car that would look familiar to Jackie Stewart: yeah, it’d probably help him adapt, but not enough to be competitive with an actual car.
Dig the idea of this product, will give it a whirl tonight.
Source: attorney, former dev
- It's not about being flummoxed, it's about being annoyed enough not to give it a chance
How much less adoption would Rust have gotten if it looked like OCaml instead of C++?
Its adopters are not stupid, they could have figured out alien syntax if they were already convinced of the benefit. But selling someone on an entirely new substrate for their professional work is a huge ask. You need to make it as immediately-palatable as possible, or they'll just keep on sailing without giving it a chance.
- As much as I wish the world to be different, I've heard so much whining about the Ada language's not-C-likeness that I tend to agree with you.
- > Rust mimicked C++
if anything, it didn't mimick /enough/
- I really like the idea. I could see some of my academic collaborators use something like this because it has features typically only supported when working with plaintext. A lot of academics do not love working with LaTeX.
But I would push back a bit against the UX and it being a "better Word". It is not immediately clear from looking at the website whether you support tracking changes. If you support editing Word documents, why aren't basic editing features, like font selection, size and weight, exposed in the UI. (I am viewing it on mobile Chrome and I might have missed it because your page doesn't support pinch to Zoom.)
You don't have to make it look like Word but it must be designed to facilitate common interaction patterns needed for working with Word documents.
(If you are building it on top of VSCode you could use its multiplayer features, which could be a good sell. )
- Figure out how to make it uncompromisingly productive for power users and then dumb it down, not the other way around way around
- There's a couple ways to skin it. In fields where people are happy with products, i think familiarity is good. In fields where people hate the products, you get to go in tabla rasa. In this case they take advantage of the form of the interface through multisearch et al. Instead of resembling legal software, I wonder if they should resemble a court or a briefcase?
- Ha, I had the same thought a while back along a slightly different vector (legal-adjacent technical writing). I ended up writing a blog post of my wishlist of features Word has that static site generators like Hugo don't appear to, yet. [1]
I think there's a lot of money to be made in this arena, especially given that LLMs are much easier to integrate with plain text files than with Word documents.
[1]: https://hiandrewquinn.github.io/til-site/posts/things-word-h...
- Much (but not all) of what you are looking for exists in the reStructuredText [1] space. Sphinx [2] is an SSG focused on technical writing about software that you may find worth exploring.
Also, the scientific text community has been pushing MyST [3] which is an attempt to take some of the best ideas of reStructuredText and reapply them to Markdown-style syntax as a baseline. The MyST tools are a lot more recent and don't have the maturity just yet of Sphinx (including the larger ecosystem such as SaaS hosts like readthedocs).
[1] https://docutils.sourceforge.io/rst.html
- RST's syntax has always turned me away, despite its extra power here, but MyST looks really interesting. Thank you!
- I’ve been dreaming of a better contract writing tool for a while now.
I’m not a lawyer but I draft insurance contracts and work with reviewing lawyers closely. As a former software developer I miss version control, partial includes, conditional logic, etc. I am shocked at how poorly supported the business world is by the ubiquity of MS Word.
I’ve been experimenting with Typst now for some time and it has a lot of what I want in creating and versioning documents but I believe may be too technical to become integrated with existing workflows and the non-technical users engaged in the development process. Basically my experience is normal users tune out once you get outside of even basic MS Word.
I really want a great tool to exist but I’m afraid I’m an outlier and unique in my technical ability in this space. Nice to see others interested in such a tool.
- I’m part of the team behind Zoho Contracts, focused on simplifying how businesses manage contracts across their lifecycle — from authoring, approvals, negotiation, and signing to renewals, amendments, compliance, with comprehensive analytics built in.
Our document editor is powered by Zoho Writer, offering all the capabilities of a word processor along with versioning, document assembly, and automation features. On top of this, we’ve built structured version control, clause-level change tracking, and workflow-integrated collaboration. This enables legal and business teams to work together seamlessly without relying on external editors or juggling redlined Word files over email.
Just sharing in case anyone else here is tackling similar problems or interested in the space.
- Ah, a kindred spirit. I have been drafting part time for a local firm, and I feel like i’m on the cusp of a brilliant concept for pulling documents together, presenting case status to the lead lawyer … but I don’t have the time to coalesce my inklings into a tool.
I think we technical folk need to build technical tools for us to use while we explore the space and iterate on something that the normies will accept.
If you find anyone willing to invest money so a team can spend time on this, please let me know! :-)
- > "Finally got sick of diffing contracts in Word and emailing PDFs back and forth"
this is the actual iceberg. forget ai clause generators and buzzwords, 99 percent of the pain is version chaos. localfirst editor is cool and imagine pairing that with proper gitstyle branching across teams. redlines you can merge without manually eyeball.
- Word has offered redline merging for over several decades...
There's a reason it's still the standard in the legal industry.
The funny thing is that Word has tons of functionality that techies aren't aware of because they don't actually use it so they keep building products around features Word has had for years. And then they wonder why their startup failed to get any traction.
- No, it doesn't work. I'm a long-term lawyer (and a techie), so I'm fully aware of Word's features and shortcomings. Most corporate lawyers use a product called Litera which is pretty good but a clunky COM add-in.
- As I said in another comment: you're basing your entire product around doing one feature, but your competition is the entire package.
Redline doesn't appear to be working in Firefox in the web demo you have available. As that is supposed to be your killer feature I would say that your product isn't yet in MVP state. Also, the UI is quite bad and not the slightest bit intuitive; it's the kind of UI that only makes sense once you already have been using it for a while. As you pointed out, most firm lawyers already know and use Litera, so you need to not just be better at your one chosen feature but you also need to be easier and more intuitive to use and you're not.
It's okay for you to be offended by this criticism; this is your baby. But I'm being realistic here. You can choose to ignore critiques and die stillborn, or address these complaints (which other comments have also pointed out) and actually make something that a small but sustainable niche of lawyers will happily use.
- That's not the killer feature. I'm not sure where you got that impression. It's the integrated whole which is the feature. Sorry it seems not to work on firefox, but I'll definitely work on that. It's a desktop application with a "web preview" that is being presented here. Most lawyers never interact with the web preview (or the website for that matter) because it just arrives on their desktop.
Agree to disagree on the UX, but points very much appreciated!
[Edit: what OS and generally what type of edit? Firefox on Windows is working, but perhaps there's a specific edit which caused it to crash. Thanks so much!]
- Consider pitching it as: use the same Word you always have, and use these additional tools (diff, go to, etc..).
I'd expect most firms to have their own systems for backup, versioning, access control, approval, metadata, etc.. or at least a human process for such. It should be much easier to sell the "extra tools" than software that changes their process.
- Firefox on Windows was definitely not working.
Hard disagree on the UX. Remember that it's not what you think of the UX, it's what your users think of the UX. This is basically like GIMP or Darktable; I'm sure it makes sense to power users who have invested a lot of time, but unless you want that tiny group to be your market, you need to make the UX way more user-friendly.
- yeah word has redline merge, but it breaks the moment edits arent linear. try merging three branches of the same contract across two firms and an in-house team. tracked changes turn into spaghetti. no merge conflict UI, no real version graph, no concept of rebasing edits. you get a stitched-up doc with 20 authors and no idea who changed what when. and once someone accepts changes early, half the context’s gone. legal folks make it work, but that’s survival, not support.
- It’s not good enough. I know because I had to use it for comparing different versions of contracts and it was painful.
- Couldn't enter Japanese into the web version. Looks like it trying to read keys directly. Copy and paste don't work. Right clicking doesn't bring up a context menu with system options so no looking up words using the locally installed dictionary. No OS level spell checking that uses the user's dictionary.
I guess all of that is TBD though I suspect based on the tech choices will be way harder than it sounds.
- Copy and paste don't work on the web version, but they should work (including pasting formatting out into Office products) on desktop. Similarly for fonts. If you're using a font that contains Japanese characters it should render. It doesn't (yet) do a great job on falling back.
Try the download!
- It just warms my heart to see so many lawyers pining for git-based change management and drafting-as-code all in one place. I KNEW I WASN'T ALONE.
- I created an account just to marvel at this very concept
- This looks great! I’m really stoked to see egui being used for the desktop app. While I’m not a lawyer, I was wondering about the potential for external references to cases, i.e doc1 references a case which isn’t present locally, which can then be navigated to via something like “go to definition”. Maybe something like an indexer that crossrefs on a database of legal cases? Do you have any thoughts on some other use cases? The idea of an IDE for lawyers is super cool, can’t wait to see where this goes!
- Thanks so much. Yes, the plan is to package libraries along with the product to allow for all kinds of external entities to be resolved.
Egui is great!
- It's a catchy name, though ironically tritium is not legal in the US, generally[1] (for "frivolous purposes"). Guess this is serious software!
- I pine for a DSL for legal documents, both because it’s tedious and tiresome to parse prose like this:
> Except for persons who manufacture, process, produce, or initially transfer for sale or distribution self-luminous products containing tritium, krypton-85, or promethium-147, and except as provided in paragraph (c) of this section, any person is exempt from the requirements for a license set forth in section 81 of the Act and from the regulations in parts 20 and 30 through 36 and 39 of this chapter to the extent that such person receives, possesses, uses, transfers, owns, or acquires tritium, krypton-85, or promethium-147 in self-luminous products manufactured, processed, produced, or initially transferred in accordance with a specific license issued pursuant to § 32.22 of this chapter, which license authorizes the initial transfer of the product for use under this section.
... and also because it is ambiguous / error-prone / subject to interpretation, especially when figuring out antecedents of pronouns, referents, and textual boundaries.
I tried four times to read the above by paragraph without reformatting it with some parentheses etc, but failed.
- One thing I would really like to see is the mathematical and/or notation with the tall single curly bracket (with nesting, when appropriate).
I've seen a bulleted list being used for both conjunctions and disjunctions within the same document and in both cases it was not obvious from context (it was related to conditions for receiving funding)
- I have designed CSTML with that exact set of usage and features in mind. It would be absolutely perfect for what you describe. I badly need investors though. Know any lawyers interested in investing in a product like you are describing?
- .... I think it means that you can make self-luminous products without needing a license, as long as you got them from somebody who does have a license.
- I think that's pretty much it but IANAL. Tritium vials are available for sale for use in self-luminous products. The vials themselves are pretty expensive for what they are, and they come with documentation about who initially created the vial (or how it was imported).
I have a gun with a tritium-based night sight (so the sight dots glow with no light), and it came with documentation about the provenance of each of the three tritium vials.
I also believe it is a crime to break open a sealed tritium vial.
- Can I trademark that slogan? :)
- Really cool to see a native app instead of another Electron or browser-based tool.
I'm curious what was your experience like building this in Rust? Also, how did you find working with egui, what made you choose egui over other UI frameworks?
- Agreed! I don't think lawyers would have accepted an Electron alternative to super fast Word. Rust gives the raw speed and safety necessary to compete.
It's my first Rust project, and I've found Rust to be amazing once you cross over the learning hurdle. The biggest issue was of course the borrow checker, but for a project like this where you aren't really iterating much on the design (as opposed to say a game dev), it lets you fly. It saves you from all the big mistakes and allows you to comfortably use threads and things. No idea how I would have made it without rust_analyzer, though.
Egui was simple to get going, while it has some downsides being an immediate mode UI, those are mostly overcome by the caching necessary for rendering documents, etc.
- why you choose egui or you just choose based on what you commonly used??
- I had been messing around with Imgui relatively recently and enjoyed the simplicity. Prior to that I was doing stuff with React which is kind of the polar opposite and found that to be super laborious. So when I saw egui, I jumped at the chance.
- Hi! Tech/cyber person at a law firm here. Major concern I can see is “will this make the formatting go haywire”? Also which kinds law practice groups would benefit them most. Finally - how can this be collaborative ?
- The promise is what you see is what you get between Word and Tritium [desktop].
Transactional practices like RE, funds, capital markets, finance, derivatives, M&A are the target audience.
The roadmap includes a shared history but iManage integration is also in the works. So the experience will target google-docs like collab with something more familiar in terms of version control. That's on the roadmap though.
Can we chat offline? drew@tritium.legal
- Congrats on the launch, really great stuff. As a software developer who has been studying (very slowly) a law degree, I can really see how products like that improve existing processes can really fill a need. I've also seen some former colleagues gain a lot of traction in a very similar legal process improvement space.
For a completely unrelated use case, I've started using it as my docx viewer on Linux, and so far it's been great (and solves one of my pain points moving from MacOS).
- I like the idea! I wish I could use git / PRs to do rounds of edits on legal documents instead of whatever Word’s track changes is.
Speaking of, could we start using version control for keeping track of laws and updating old laws? It seems to me like a much better system than randomly burying in a new law that it strikes out some text from an old law.
- Reminds me of this old HN thread: https://news.ycombinator.com/item?id=4353389
- One thought regarding footnotes. I often find myself searching in the reverse direction, i.e. I have a footnote, where is the superscript to which it belongs?. This is quite difficult to do by eye, so perhaps some goto reference type functionality could be useful in this case.
- Trivial in LaTeX, does word not do that?
- Great idea! Definitely coming.
- I wonder if textbooks and papers could be easier to understand if they had a "go to definition" functionality for technical jargon, notation, or reasoning.
- When I went back to college to finish my degree, some of my classes used online textbooks from a couple different systems. Most had a simple link to a glossary for key terms, but some took it a bit farther and had a nice pop-over widget. The nice ones also had the ability for you to highlight and annotate passages for your own notes. It's less fun though, if you're like me and have a hard time reading long-form content on a laptop or phone. I ended up getting one of those eink Android tablets to make it easier for me to get through the reading.
Shame is that monetization around them is even more exploitative than normal textbooks. You don't own them, so you can't keep or resell them once you're done, and you typically lose access to it about a week after the class ends. Many courses also issue assignments and grades through the e-textbook, so you're forced to buy it at a price they decide. Fortunately work reimbursed mine.
- This is pretty interesting! Did you implement the DOCX support and rich-text editor from scratch? I’d be concerned about interoperability with other editors — a semi-compatible editor losing content/comments added by other software could be a huge problem.
- Yes! From scratch. It started with a docx library but had to be re-implemented from the beginning because that library dropped data that wasn't implemented. Tritium's docx implementation is more permissive such that it can gracefully failover to just pure XML if it can't parse an element via the AST.
- Hi, good to see you respond to criticism here, too. Personally, I can't try it locally right now, and the web demo refused to load on Firefox. On Chrome, it loaded, but it's... very slow to load files when I click on them, and there is a visible delay between taking an action and seeing that action reflected in the demo.
I bet this is a WASM limitation, I work with WASM and with Rust every day (though sadly not related lol), so I know the pain to some extent. Just please but a banner at the top saying "This preview has limited performance and responsiveness. The native app doesn't have these limitations and can be downloaded here: <link>", or similar (assuming you are aware of serious performance limitations in the browser. If not, and if your native app performs the same, please use profilers to figure out whats wrong).
- Thanks so much. It does have this banner: "Some features are unavailable in Web Preview. <link>Download the Desktop version</link> for full speed and functionality." which is intended to capture that exact issue.
I'd love to coordinate a demo for you personally if you can spare the time. I'm at drew@tritium.legal or you could drop your info here: https://tritium.legal/demo. I'm familiar with working with and onboarding to regulated IT departments.
[NOTE: some of the speed issues are coming from the pipes clogging up due to the traffic. There's no CDN here unfortunately.]
- Just a thought: I think it would be neat if you could include one of Mathew Butterick’s fonts (https://matthewbutterick.com/), as a fellow lawyer/software developer. I don’t know how practical that is, but it’s a smallish club and they are very pretty fonts.
- Thanks so much for the idea. You may already know this, but fonts are actually little pieces of software subject to their own licensing terms. For that reason, Tritium (like most word processors, I believe) relies on the system fonts available for rendering. Those are already owned by the user. I'll reach out to Matthew and see if there's any possibility for collaboration.
- The letterforms themselves, on the other hand, might be uncopyrightable, depending on the jurisdiction. But paying for the fonts you use is just common decency – especially if used in a commercial product.
- minor nit: cmd+z is ctrl+z in macos, which felt counter-intuitive on an editor
IANAL: idk if lawyers dont do pdfs but tried some research papers and PDF rendering could use some love (MacOS)
- Noted, and to be fixed. Thank you
- I had edited prior message but would be great if supported PDF rendering as good as docx! (for research mostly, not a lawyer)
- One thing it does is cast the PDF to grayscale to render for speed (lawyers rarely care about the color of a legal doc in PDF), so perhaps I'll make that an adjustable setting which will trade off speed for clarity. Otherwise, it uses PDFium for PDF rendering so it should come out just as well as what you see in a Chromium-based browser.
- might be an issue with DPI / Retina screens on macOS?
it's really more blurry than any pdf on chrome https://imgur.com/a/AElOuaA
- Oh, yes, that is also a cheat code to render them quicker -- it downsamples the render to save time. That will improve in future versions as Tritium uses spare cycles to increase the resolution.
- ^ yes it does greedily ingest the PDFs to allow for instantaneous search. What it needs (and doesn't yet do) is at least multi-thread that parsing step to get a 2-4x speedup.
- I also noticed when i opened a folder with hundreds of big pdf's it choked on it
seems you're doing work on all files when loading, you should be more like lazy-loading?
- If this is Electron, try pdf.js - really good rendering, you can create a text layer (for text selection, etc). Probably the best result per effort you can get
- care to link to repo? alwayss good to have one of these at hand
- > Tritium is implemented in pure Rust.
This beautiful software that looks a bit like VS Code, what did you use to make it? I'm guessing Tauri but curious if you used something else.
- That's very kind -- let's hope the legal profession feels the same way. It's certainly inspired by VS code. It's using egui (https://github.com/emilk/egui) under the hood. Big hats off to Emil Ernerfeldt and the team at rerun (https://app.rerun.io/) for the incredible work on a great immediate mode GUI library.
- I did send it to a lawyer I'm friends with, their hesitation comes from putting anything confidential on "unknown software" so I think you should really focus on highlighting any kind of metrics you keep, and anything that could be fully relevant to a legal professional. I also recommend, I think you mentioned AI is possible, making that opt-in only.
- Yes that battle is won by getting the IT/infosec team's approval for the desktop application. Lawyers really don't like the WASM version because it seems like you're uploading docs to some server (you aren't).
Thanks a ton for the feedback!
- My understanding working with law firms was that they are pretty bought-in to the Microsoft Office ecosystem, how well does Tritium integrate? Is the docx format fully supported? Can one person use Tritium without affecting others? Other than tabs, what does Tritium offer that two Word panes and a file browser pane tiled on screen can't cover?
I am interested in developing software in this space, so these are earnest questions and not criticism.
- > My understanding working with law firms was that they are pretty bought-in to the Microsoft Office ecosystem, how well does Tritium integrate?
Absolutely. Overbought. They're owned by Microsoft. Go to a legal tech conference and there are thousands of vendors and not a single MSFT representative. All they want to do is push more Azureware on the deep pockets of profitable firms.
> Is the docx format fully supported?
It will be. There are certainly edge case features that don't render correctly yet, but those will come. The 80% that we care about should work. No data will be dropped, as mentioned elsewhere it will just look bad and gracefully degrade behind the scenes to a safe representation that ensures the data isn't lost.
> Can one person use Tritium without affecting others?
Yes, it's totally private and secure. Using Tritium doesn't require any cloud access or anything like that (other than to phone home with the auto-update or your LLM integration). I'm going to link the history to a separate hidden directory in the filesystem a la .git in the future which will allow some basic multi-editor features.
> Other than tabs, what does Tritium offer that two Word panes and a file browser pane tiled on screen can't cover?
Great question! It does the things lawyers care about: help them pick out symbols (defined terms, specifically) and run diffs (redlines) cheap and quick. It also renders PDFs (using pdfium).
> I am interested in developing software in this space, so these are earnest questions and not criticism.
Drop a line to the email in my bio. I'd love to chat offline.
- Not familiar with law enough to understand how to use it. Maybe you could show some boring hours long streams of using it in the real world and we would understand
- It probably wouldn't make sense to show lawyers what we do, either, but there's a kernel of truth there: the product needs some development on the onboarding.
- Congratulations on the release! I don’t have much to add, but I wanted to express how much I love hearing about people with no formal software background who identify problems in their daily lives, plan, build, and release software to address them. Best of luck!
- Could this also be used as a user-facing tool?
e.g. to understand Terms of Use, finance and purchase agreements, that sort of thing?
- Yes, although that is not the target audience and we'll try to avoid spending time generalizing the product too much for laypeople to remain laser focused on the target.
- IANAL but this looks great! Congrats :)
My pottery teacher runs a law firm though, I’ll show it to her. Do you know if there are many differences in workflow or terminology between the US and UK?
- Actually I’m based in the UK and can say corporate law practice is nearly identical. Thanks for sharing!
- Hey guys - I really appreciate the love from Hacker News. It's a real honor to get all of these votes and comments. If you like the idea and aren't a lawyer but want to help the project move forward, please suggest Tritium to the corporate lawyers you know.
- Probably dumb question:
Given that many lawfirms bill by the hour, are there incentives to make their work more efficient? I.e. if a firm were to adopt this tool, can they practically charge more per hour than a firm that does not?
- Yes, they are not incentivized to adopt new technology in their current state. The senior partners don't want to wait around for the eventuality of charging more per hour. That's why Tritium is marked to in-house lawyers for now.
I talked a little about this back in September: https://www.legalinnovators.co.uk/post/legal-innovators-uk-t...
- As a private practice lawyer in a tech-heavy firm, I can assure you that not all of us are stuck at the wrong end of that paradigm!
- I think a more user-friendly UX would really enhance the experience. The idea is fantastic, and I truly believe it's going to do well!
- > There are sub-par differencing products that make `patch` look like the future.
I absolutely love https://www.draftable.com/compare - it’s an incredibly intuitive presentation of diffs from arbitrary documents, with fuzzy matching even between file types. It’s great for everything from “what did my cofounder change in this version of the deck” to “how can I quickly scan to understand how these PDF documents have evolved from a much earlier version.” Be careful with data security if uploading sensitive documents, of course. But it’s as effective a general-purpose diffing tool as one can imagine.
The real leap past this would be contextual AI extracted takeaways during the review or editing process, which begs for a specialized IDE. Makes me excited to see that this space is evolving!
- I've added a very simple demo request page for folks who want to try Tritium at work: https://tritium.legal/demo.
I'd love to run a demo for you or your legal team.
- It looks like code editor with symbol references. Is that all the functionality? I expected document to be tied to some law (or part of) and use outline of that law as outline for document, and then populating document to cover all the aspects of selected law, with AI, and indicating which generated parts were reviewed by human.
- and then populating document to cover all the aspects of selected law
I'm fairly certain lawyers exist specifically because this is infeasible.
- Not only that but: which subsection of law is specific to this case? What additional documentary requirements come with citing that law? What’s the presentation strategy for the target opponent/lawyer/court?
- This seems pretty cool! I tried it out but I ran into an error that froze the entire app on the preview. Seems to be related to max pages per paragraph.
- Ah yes, that is a bug where the layout engine can't fit it correctly and gets stuck in a loop. It maxes out rather than overflows, but the same effect. It's being worked on, and sorry for the inconvenience.
- I tried coming back to HN using my mouse's back button, but it seems Tritium is eating mouse back button events.
- Apologies if that's the case. It's just a WASM application intended to demo the real desktop application. No nefarious purpose there, but perhaps the limitations of the "preview". Try the desktop version!
- Recognizing touch controls on the document viewer tab would be nice (ex two finger drag is pan, pinch to zoom, etc).
- I was wondering why the creation of docx files does not seem to have any formatting options but just plain text? Is this not required in legal context?
- It actually does on the desktop versions. The "web preview" doesn't have any access to the browser's fonts, so it's limited to an open-source embedded font. Check out the downloads!
- I don't know what sort of bug this is, but if I try the preview in Firefox on macOS and hit ' or " the editor inserts the word "Dead". It looks like the editor is using ctrl+z on macOS which is... a choice. On the other hand, at least it seems to treat the home/end keys normally, which is infuriatingly hard to make macOS do.
That's probably a dead key issue (one reason custom renderers for web applications are so tedious to program) but I find it very funny to have a dedicated "Dead" key. Useful for people dealing with wills a lot, I suppose!
Edit: same is true for Chrome, so it's probably a Tritium issue and not a browser issue...
- Awesome bug report! Thank you. Let me check into it. Would be even better to understand if you could replicate it on the Desktop application.
- Say you were going to cold email a lawyer to pitch them to use this, what would you write?
- Probably something like: "
[Person] - hope you're well! I wanted to put Tritium on your radar. It's a word processor jacked on steroids built just for transactional lawyers.
From built-in defined term annotation to multi-document search/replace to redlining and much, much more, it will help your team work faster and more effectively on existing Word documents and PDFs. You'll even pick up errors from outside counsel.
Tritium runs on Windows, MacOS and even Linux for your most tech savvy lawyers.
Please let me know if that might be good for your legal team, and I'd love to demo it for you."
- This is a bit too heavy on the feature side. As in, here is what this is, not what it will do for you.
What would you say if you were going to focus on a pain point and a problem that this specifically solved for you, that it can also solve for the other lawyers who are not using this and that is not being met by the other options?
- Take one feature: redlining. Right now every corporate lawyer knows what a pain in the ass it is to do something as simple as a diff. It takes probably a full minute (imagine if it were like that to run git diff for you!). Tritium runs the redline in microseconds, because it's built for lawyers.
- Super interesting. Working in consulting, often with corporate lawyers. Will check it out.
- As someone who is a (current) software engineer and (former) lawyer I find this interesting. Not sure if I'm willing to bet on big uptake, though, unless it was through an acquisition by one of the big e-discovery companies.
- Former attorney, now dev - sorry but hard pass on this. Lawyers (especially those in big law) hate using Google Docs because it’s too dissimilar to Word.. This is leaps and bounds different. The Steve Jobs mantra of customers not knowing what they want applies in a consumer scenario, not an enterprise / business scenario (where lost time / retraining = dollars lost).
I wish developers would think more as users and not “what would I like” more. I’m also pretty sure that I could count on one hand the number of lawyers that use Linux for any legal work.
There have been a few attempts to use diffing to solve redlining, you should look into why they have failed.
- It's not for everybody, but it's already being used by lawyers, and I'm one myself and want it. Appreciate it's not for you!
- Hey, this looks to be pretty interesting and I'm excited to see an app made with egui that doesn't look like it uses the default theme!
I have no use for this software personally but I feel like it's pretty important for me to point out the fact that in your license agreement you misspelled the name of the company as Tritium Legal Technlogies (Technl instead of Technol).
Cheers on your product. From the small showcase it seems to be extremely fast. Developers actually caring about performance brings me great joy.
- The incredible irony of a typo in legal documentation related to a legal drafting application is not lost on me. Thanks very much for the positive words and the correction!
- Congrats! Great stuff
- This is really cool. I’ve recently also had an observation about the modern lawyer’s toolset: they have no idea what version control is. Lawyers email around countless duplicate copies of .docx files as their version control. “Red line” files only hold a single revision. This can definitely be improved upon.
- What's wrong with MS Word again?
- There have been Word add-ons that do all of this for a while now, specifically targeted at lawyers.
Why would a law firm give up Word for this? That's your competition and unlike techies they're not going to waste time on an MVP, they want and need a finished product.
- Because the add-ins are crap and they know it. But you're right: the risk here is purely technical.
- I'm excited for the prospect of lawyers running Linux as their daily driver
This does not benefit your customers in any way.
It does not benefit their clients, either.
And brain activity around it is a distraction from what your business does.
At best.
Good luck.
- That's a fair take at surface level, but building a cross-platform application does allow for a broader class of contributors who can also dogfood the product.
I'll have to do another write-up about it sometime, but a lot of Tritium's automated tests are written in docx files. So building for Linux as an afterthought allows an employee to develop from their preferred platform (if it's Linux) while still getting the full experience. Also there is something quite informing about discovering differences between platforms that help you to better understand the capabilities of each.
I also do believe one day we'll see, e.g., crypto startups' lawyers using Linux. And they'll be happy Tritium customers :)
- If your target customers care about linux and rust, you have probably over segmented the market.
- Yeah, that's true - they really don't. But it helps with the DDQs when you can tell their Infosec people that it's a typesafe language. In the end it's another bullet point but not much more. It's great to be able to run it on Linux and develop in Rust though.
- Looks great, sharing it with my legal team.
The "Fetch Example" button on the web demo doesn't seem to work. It would be nice if the web demo was pre-loaded with some stuff.
- There should be a "build" button that pulled all the legal codes for the target jurisdiction and other legally binding documents and checked if everything checks out.
And to achieve this you would have to create a machine readable format for legal documents, and have a library of them already converted to it.
Then you could have a linter that highlighted that you made a logical mistake or did something wrong from the perspective of a legal guy.
- Spent 15 seconds waiting for the spinner to resolve before I gave up.
- Apologies for that. I thing the pipe is getting hugged a bit here. Unfortunately it's a bit lean so no GCP outages to blame it on!
- [dead]
