Show HN: Floro – Visual Version Control

[jsunderland323]

Hi HN, we’re building Floro (https://floro.io), an open-source, offline-first visual version control system that allows you to merge and diff graphical content. Demo video here: https://www.youtube.com/watch?v=5fjixBNKUbM.

We were a YC W21 startup (Cheqout) that originally worked on restaurant tech. We ended up pivoting after the pandemic and decided to build Floro due to a lot of problems we encountered while working on Cheqout.

We struggled a lot with string content and dark mode, especially when it came to static assets. We were a cross-platform product, so everything was an SVG. What we wanted was a way for our designer (who cannot use a command line) to be able to check static assets into our codebase and be able to manage our color themes without us having to manually edit the assets ourselves. We also faced a lot of problems with i18n and keeping translations up to date. Both problems felt kind of similar, they’re both essentially just key value solutions that require people who aren’t software engineers to edit them.

This led us down a path of searching for a way to incorporate something like Dropbox into git. We didn’t want a content management system, we wanted something where we could diff and merge our static assets without requiring the user to know how to fix conflicts in plain-text or binary. We wanted a way to reference something like a snapshot of a tar of our static assets so we could idempotently rebuild our application and add type-safety to our assets. Eventually, we found a trick to diff and merge a certain type of tree structure that fit these problems well. After a bit more experimenting around, we figured out how we could write an interface to make UIs that could be diffed and display merge conflicts.

To show what visual version control could be applied to, we decided to build four plugins (applications that can be diffed and merged in Floro).

1. Text - This plugin is basically a replacement for i18n strings. It supports rich text, typed variable interpolations, conditional logic (for things like pluralization), links, ML translations, and a plethora of other features. It’s also sort of an IDE/TMS for translators & copy editors.

2. Icons - This plugin allows you to recolor an SVG asset so that all the colors are consistent with your color palette. You can automatically generate dark mode (and any other themed) versions of your assets, as well as versions of your asset that change with state (e.g. hovered, etc.) by applying themes to the asset.

3. Themes - This plugin allows you to create themes from your color palette.

4. Palette - This plugin allows you to define colors and shades that can be consumed by other plugins or used in your code for managing your app’s colors.

Since Floro is an offline-first desktop application we realized that we could allow users to test their local content out by building a browser extension that would allow them to override the state of their production websites and apps with the local content from floro. Floro essentially creates a localhost environment out of production apps, which allows non-technical users to treat content similarly to how engineers manage code. The demo video (shown above) does a good job of showing how this works. We also have a demo of how this works for mobile apps (https://www.youtube.com/watch?v=Om-k08GDoZ4). We are fully open source (MIT licensed). We intend to monetize with consulting and private hosting. Users are more than welcome to self-host and build their own distributions of the desktop application and all the plugins we have created.

This is really our launch (anticipate some bugs but nothing serious, restarting the app(s) takes care of most things). We’ve now built four applications with Floro (including our website) and feel confident that it’s ready. We’ve spent 18 months getting here, we hope some of you like it!

Thanks!

Jamie & Jacqueline

[ThinkBeat]

Version control needs to be visual and pervasive.

It also needs to deal with whatever files you want to dump into it.

Dropbox (as you guys mention) as well as Google Drive and OneDrive and I am certain a lot of others have already implemented.

All files are versioned and for the most part you dont have to do anything.

All of this is clear with it comes to Git, with the 100+ different programs trying to give people a visual experience, over cryptic and inconsistent command line interface.

I am working on a simple proof of concept on a new way to visualize changes in code. Still early. It is far from trivial, but I think it is needed. There is a good chance I will fail of course. But if enough people think about it someone will figure out a better way than what we have now.

Well some of the work has already been done, for a long time in more integrated IDEs where the environment is much more interactive and interlaced.

[hdarshane]

Check out some of the work at https://www.inkandswitch.com/patchwork/notebook/

[jsunderland323]

I'd be happy to hear about your project and share my learnings if you want to schedule a time to talk. I've put a tiny bit of thought into this problem and would love to pass on what I've learned.

The way I originally conceptualized floro was a way to version anything without requiring plain-text (ie. higher order versioning). I've strayed quite a bit from that belief and I think there's a lot of complex trade-offs involved in version control and what makes sense for specific use-cases. Floro would be trash for game development but that is an industry that sorely faces tough versioning problems involving graphical data.

Please feel free to reach out to me if you do want to chat. The discord for floro is listed on the website but you can also just check my HN bio for my email.

[ActionHank]

I don't know if I am your target audience, but it seems like it's doing a whole lot more than most people would need.

I feel like there is huge value in version control that supports various binaries with custom diff support. Perforce, git-lfs, etc. offer binary version control, but not custom and useful diff tooling per binary type. Kaleidoscope, Beyond Compare, etc. offer some improved diff tooling, but not for a wide variety of file types.

That seems like it would be the essence of a product like this.

I suspect that many of the people who influence the adoption of VCS are likely deeply technical and will likely actively avoid products that are opinionated on the target output when using the VCS.

[jsunderland323]

I think you're probably correct that you likely aren't the target audience here. Version control is a loaded term. This would be a terrible replacement for perforce or anything for diffing something like a CAD file.

The real focus of the system is for things that are better managed by people who aren't engineers but end up interfacing with code very tightly. The idea was to focus on the peripheral functions that come up in UI engineering and enable e.g. translators, copy editors, and designers to essentially commit to a codebase without having to understand git or know how to handle plaint text merge conflicts.

> I suspect that many of the people who influence the adoption of VCS are likely deeply technical and will likely actively avoid products that are opinionated on the target output when using the VCS.

I totally agree. You can modify the output to your hearts desire. This was a big part of our design.

[IshKebab]

Git does support custom diffing algorithms and tools.

[account_created]

I was building a very similar solution two years back after seeing the struggle of managing the assets for the design teams. Mostly people were using google-drive to share/collect/update the assets which was not very systematic. I envision my solution to fix this with the similar insiparation of VCS and proper integration with existing design tools, but after some time realized that the solution was not good enough and it quickly became too technical for the design folks.

[jsunderland323]

I mean this is the struggle. And props to you for building that. It's an ugly problem.

I actually do think (and have personal evidence now to believe) that most functions adjacent to engineering can learn distributed version control. Once you start using it, you really don't want to go back.

We've internally adopted trunk based development for our assets and it gets rid of 99% of the confusing parts of version control to not use branches (I know blasphemy). My designer just pulls and pushes on the main branch and I do the same -- we've had very very few merge conflicts and none that couldn't be resolved in 30 seconds.

I feel silly now having spent so much time on branching as a feature. It makes a lot of sense for plain text and code but it probably doesn't matter that much (for small teams) for visual things. Merging has proven to be invaluable to us though.

[ramesh31]

Love the idea but please pay for a UX professional. This UI just screams "we have $component_library, why would we ever need a designer?".

[jsunderland323]

we do =D ... She's still getting her chops though.

We'll probably end up using webflow to market to designers. We were going for hackerish today.

We actually didn't use any component library. We designed all of our own components in-house

[1123581321]

The two part technical overview was a fantastic writeup and illustration! I didn't understand why you were using that JSON structure to illustrate everything until I watched the demo video of your diffable UI. I hope it catches on, but am wondering if you're planning to apply the same techniques to traditional designer working files.

[jsunderland323]

Thank you so much!

I put so much effort into that and you are probably the only person on earth who has actually read that thing in its entirety (aside from my poor, ex-midwife, mother who has no idea what I'm talking about).

> but am wondering if you're planning to apply the same techniques to traditional designer working files.

I would love to. When I discovered the JSON trick I felt really confident that this was the inevitable direction of the project but after writing a few plugins I'm not exactly sure how practical I really think that is now. It's great for primitives but I'm apprehensive about anything that starts to get into the no-code territory. I think it's possible but there's some mathematical and UI challenges I've got to overcome.

To make something more complex than a TMS system I really need to make the schema language a bit more robust in a way that is probably beyond my engineering skills. I need to find someone who actually knows how to write compilers and understands category theory (not me haha). I think this could be applied to something more general like figma/sketch though and I hope it's a first step for someone smarter than me to fill that gap.

[vouaobrasil]

Hey this is cool. I think there could be a place for a new kind of version control. I'll test it out.

[jsunderland323]

Thank you! I'll put my email in my bio if you want any help at all, It's a heavy installation (but straightforward once it's setup).

[ugh123]

In this youtube video example https://www.youtube.com/watch?v=5fjixBNKUbM

you demonstrate adding the new icon to the page and then modifying it with a hover alternative color. But the rest of the compare/diff/review workflow only focuses on the change between non-highlighted -> highlighted. To me, the important part is the addition of the icon to the page, and as a reviewer it would be of upmost importance to see the visual diff of the page before and after, rather than just an icon and it's hover alternative.

[jsunderland323]

By page do you mean like your live website with the changes?

I've thought about this too and I think down the line the plan is to be able to attach screenshots to merge requests. However, as a reviewer you can also pull down the changes and test them against your production site locally. So you can alter between the main branch and the feature branch and compare the differences like that. The benefit of this over a screenshot is it lets you actually get to see something like the hover effect in action.

[seltzered_]

Have you talked to folks behind prior startups in the space like layervault?

See http://web.archive.org/web/20150424103031/http://layervault.... and https://kellysutton.com/2015/07/21/startup-theory-of-relativ...

[jsunderland323]

Oof, sounds ominous. I have not heard of them, so it's hard for me to know where they stumbled or draw comparisons to what we've made.

To their point though, I largely agree with this, "The only thing I’ve found to be effective at dealing with competitors in early stage companies is to ignore them."

Did you ever get a chance to use their product?

This is something that really motivates me about offline first/OSS stuff though. It will be inconvenient for those who adopt if we have to shutdown but it's still possible to use floro without needing our servers. You will end up having to host your own though.

[extraduder_ire]

I like the "I'm not a software engineer" checkbox on the about page that changes the page content.

[kissgyorgy]

Great idea, but it seems more complicated than simply adding files to a git repo.

[jsunderland323]

It for sure is more complicated than adding files to a git repo. You are 100% right and I wouldn't dispute that for even a second. I'm not exactly advocating this for solo-projects unless you are already sure you want to do something like internationalize your project.

There are many problems where plain-text falls apart for even engineers though or there's some benefit to editing something through a UI or WYSIWYG rather than plain-text. If you're cool with markdown and editing SVG files manually -- do it.

The problem being addressed is when you have team members who need to do things that requires some level of type-safety but they either don't have the technical background to work with something like git or it would be non-sensical to resolve the conflicts in plain-text. The idea here is for designers to basically take control of things like icons and theming and for translators to take control of i18n. Their work is state that can be used to generate a type-safe API for engineers to consume those assets.

[Pwntastic]

Why does the main product page attempt to connect to a localhost port? It looks like it's trying to hit a socket.io port, but that seems pretty unnecessary for a landing page?

[jsunderland323]

It's testing to see if the daemon is running from the electron app. It uses the connection to the browser for things like sign in and verification and for being able to redirect links into the electron app.

https://github.com/florophore/floro-mono/blob/main/packages/...

The reason it's happening on the landing page is because we use floro for editing the site and testing our changes offline first before pushing.

[amir734jj]

One of struggles we had at Microsoft is versioning power bi pbix files. Someone publishes a change and the old version is gone unless they saved it somewhere else.

[SkyMarshal]

Pretty cool. What framework/tech did you use for the multiplatform app? Curious for a future side project I may start on soon.

[jsunderland323]

Hey Thanks!

Just electron & vite. I might actually migrate off electron, Tauri (https://tauri.app/) seems to be getting more stable and it's gotten great reviews.

I think this is the boilerplate I used though https://github.com/cawa-93/vite-electron-builder.

[password4321]

Plastic SCM was acquired by Unity so I guess there's precedent.