Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
111–120 of 269 posts
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#112Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#113One of the most important features to get right for tools like this is collaborative editing. It's incredibly difficult to get this right (live preview, conflict resolution, history management, etc), especially given how the vast majority of users are non-technical folks (which aren't used to toolks like git). Could you expand a bit on how you intend to tackle this problem in Nino?
I actually think this hyper-granular realtime collaboration like in Google docs is slightly overrated. I think it’s ok to have more a git-like workflow where feedback and changes happen over cycles. As a programmer, I don’t give a shit about your working directory. I do care, however, about your commits :) All I’m saying is this CRDT craze isn’t always necessary or even appropriate for many products. It adds a lot of…
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#114Super impressive app by the look of things, but as you asked for feedback, it is (to me) very confusing on the product side of things (i.e. what is it and why does it matter to me). As a business user it's not clear how I would use it, and why I would care. Your front page reads as: > Nino is a collection of apps that can interoperate with each other on the block-level from one uniform interface. It has interoperable…
> interoperate with each other on the block-level from one uniform interface Sounds quite a bit like Notion. A comparison would be apt. Also sounds a bit like OLE / OpenDoc on desktop, embedding an Excel sheet into a Word doc along with an Access form. If it can do that, it could make quite a demo.
But seems to have devolved into generic state synchronization library these days.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#115Super impressive app by the look of things, but as you asked for feedback, it is (to me) very confusing on the product side of things (i.e. what is it and why does it matter to me). As a business user it's not clear how I would use it, and why I would care. Your front page reads as: > Nino is a collection of apps that can interoperate with each other on the block-level from one uniform interface. It has interoperable…
My initial thought was, this vision looks like what happens when a company realizes that their core product is less valuable than everything adjacent to it and starts growing their product a dozen different directions simultaneously.
But maybe there's something different about embracing this holistic vision from the start, as opposed to trying to be focused and then getting forced into scope creep.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#116Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#117Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#118Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#119Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#120One of the most important features to get right for tools like this is collaborative editing. It's incredibly difficult to get this right (live preview, conflict resolution, history management, etc), especially given how the vast majority of users are non-technical folks (which aren't used to toolks like git). Could you expand a bit on how you intend to tackle this problem in Nino?
I actually think this hyper-granular realtime collaboration like in Google docs is slightly overrated. I think it’s ok to have more a git-like workflow where feedback and changes happen over cycles. As a programmer, I don’t give a shit about your working directory. I do care, however, about your commits :) All I’m saying is this CRDT craze isn’t always necessary or even appropriate for many products. It adds a lot of…
I have to disagree. It's absolutely necessary for a lot of workflows, especially when people are collaborating on a doc in real time during a meeting (super super common), or when you've got 10 reviewers of a doc all leaving their feedback in comments, and comments responding to comments, over the course of the same hour.
The model of clean commits works well for code. It doesn't work well at all for business team documents that are in-progress.