Live data from Hacker News

Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

nino.app

241–250 of 269 posts

Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

#241

Earlier quoted context omitted.

Admittedly, yes. This is the massive appeal of Mongo et al., or just JSON[B] columns in an RDBMS. Unfortunately, at a very deep level, that’s simply not how RDBMS works. The tuples are a B+tree, and in some (MySQL [InnoDB], SQL Server) cases everything is clustered around the PK. If you don’t create a data model that’s easily exploitable for optimizations designed around that data structure, you’re gonna have a bad t…

Nosql doesn't solve the schema migration problem. It just means you don't formalize your schema. But your code will implicitly require a certain schema anyway. Changing the schema means changing the code and migrating data. You'll have to write migration scripts and think about backward compatibility. Same problems as in sql.

The trick is maintaining a full graph of all data dependencies through the entire codebase. Then migrations can be done with ease. But no one does this. They shovel data from one database to the next, with tons of little adhoc data stores along the way.

Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

#242

Really liking it so far! An offline-first platform that lets you store your information in a central way and provides multiple forms of use and access is exactly what I've been trying to find, without much success until now. I'm not sure I've understood how to fully realise the promises of it though. I created a board, and added some records to it, alongside fields for additional data. It's not obvious to me how to u…

You raised an issue that I plan to fix soon. Currently certain fields (i.e. time range) only show on specific modules (i.e. calendar) but I'm planning to allow them everywhere. Could you share your use case on embedding a single record? I disabled that for now because I imagined people would usually embed all records together in a certain view. Hm I'll think about searching for blocks in autocomplete, or perhaps some…

Thanks for the response :D

Use cases for embedding a single record - in a bunch of kanban board use cases that involve shuffling a "unit of work" across various pipeline stages, I'd like for pages and blocks (discussion documents, etc) to be able to either link to that record (ideally with a link back as well) or be entirely represented by it. This speeds up workflow, and reduces ambiguity during communication. I'd expect, e.g. that one might create a Board representing a project and work to be done for it, and a Channel in which participants might want to write messages like "Do you need any help for @Task1 ?".

The offline mode bit - that's correct, I didn't open the other pages on my phone before going offline. I imagine it does come down a bit to what the overall impact on performance would be, but in terms of reducing the mental overhead of using a particular tool, having online devices completely sync means that if I close my laptop to jump on an underground train, I only need to quickly open my mobile app, wait for a "tick" to appear to indicate it's synced, then I'm ready (and importantly, I feel reassured that I'm ready). By contrast to the current system, I'd need to mentally try and keep track of which files I've edited recently, and which files I've already opened on which devices, and try and manually calculate what I need to open on my phone and tablet in order for me to not discover halfway through doing something on the train that I don't have access to the new resource I just made. It makes a big difference in terms of how much work and mental energy a tool is saving you, and how much it still requires of you.

Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

#243
Seems like a cool idea, and presumably for a closed source solution with a single host, trust would need building up, and the argument for switching needs to be higher than the switching costs, or people just need to be blinded by love, which may be possible! Other than the single host problem and close source, what is the situation with normal interoperability, e.g: import / export? It's also cool you seem to have clients on mobile and even Linux desktop clients.

In the open source world, there is AppFlowy, Anytype, NocoDB, and APITable too so that's some strong competition. Is there a better argument for using your tool over one of those?

Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

#244
post #240

Earlier quoted context omitted.

Admittedly, yes. This is the massive appeal of Mongo et al., or just JSON[B] columns in an RDBMS. Unfortunately, at a very deep level, that’s simply not how RDBMS works. The tuples are a B+tree, and in some (MySQL [InnoDB], SQL Server) cases everything is clustered around the PK. If you don’t create a data model that’s easily exploitable for optimizations designed around that data structure, you’re gonna have a bad t…

Yeh RDBMS is probably the wrong choice for most apps. It was good for crunching sales data in batches back in the day. Everything today is pipelines and reactivity. My dream is to have a tool to model my logical data model and then it will organize my data into the best storage and caches. I don't think any existing database today is useful.

Ah, I misunderstood your point. I disagree that RDBMS is the wrong choice. Most apps are CRUD, and have the same basic patterns.

Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

#245
I believe especially for the sheets part, there is long way to go. There are strong players like Airtable, Retable, Baserow etc - all having a good base, and it will be hard to catch up (and there are 17 more apps to do the same). But all in all, I am impressed - good luck with your journey!

Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

#246

Earlier quoted context omitted.

You raised an issue that I plan to fix soon. Currently certain fields (i.e. time range) only show on specific modules (i.e. calendar) but I'm planning to allow them everywhere. Could you share your use case on embedding a single record? I disabled that for now because I imagined people would usually embed all records together in a certain view. Hm I'll think about searching for blocks in autocomplete, or perhaps some…

Thanks for the response :D Use cases for embedding a single record - in a bunch of kanban board use cases that involve shuffling a "unit of work" across various pipeline stages, I'd like for pages and blocks (discussion documents, etc) to be able to either link to that record (ideally with a link back as well) or be entirely represented by it. This speeds up workflow, and reduces ambiguity during communication. I'd e…

Ah that makes sense. I think what you're looking for is the ability to mention records rather than to embed them, or both.

As for the switching to mobile scenario, it also makes sense. I'll think about this, it might be a button that allows you to "force sync" everything.

Thanks for the detailed explanations :)

Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

#248
post #190

Single biggest thing you need to nail down fast: the data model. It is extremely hard to shift as things grow, and without careful thought, it’ll turn into a horrifying miasma of JSONB columns, duplicated data, orphaned rows, and garbage performance. Customers are going to store surprisingly large items in Docs, where you’d be tempted to inline them instead of offloading to S3 et al. Chat practically needs to be its…

The problem with modern development is having to nail down the data model first. I wish we would develop software where the data model could easily change. To do this every data dependency in the system needs to traceable. Nothing does this so far. And everyone just picks a database off the shelf but none are even remotely useful for this.

I'd rather the data model be designed properly upfront so that it doesn't need to change, but can be extended with new functionality.

Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

#249
post #28

As no one has asked so far, I’ll have to do it, how does this differentiate itself from Lotus Notes?

That was my first thought as well - and also I had to reminisce about how sad it was that two of the biggest powerhouse technology companies from the early 1990s are no longer: Lotus and Novell. It would have been hard to imagine in the networked PC environment of the early to mid 1990s that those two companies are no longer around, one swallowed up (and spit out) by IBM and the other decayed into pieces. I wonder which of today's technology powerhouses we'll be reminiscing about 30 yrs from now.

Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)

#250
post #8

Super 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…

I totally agree. Coming across Simon Sinek's 'Start with Why' has helped me a great deal in communicating in general. Even in conversations this applies: https://www.youtube.com/watch?v=u4ZoJKF_VuA I also suggest reading his book. In terms of this theory you should communicate like this: Why, How, What You are starting from your 'What'. I haven't really grasped the core of your product, but to restructure it could be…

Good call, I'm also a fan of Simon Sinek.

Thanks guys for the feedback. I think it's pretty clear what should be worked on next.

Post reply on HN