Coda is a successor to Excel that
- makes you bring order to your data, and
- lets you build docs that are much friendlier to use.
5 Likes
Some are web version excel + apps , like airtable . No docs. It’s web SQL.
Some are outline, like dynalist ,workly , transno. bear. mubu,
Some are just simply move to the web, like shimo - simple Office suite + mindmap ( non-editable)
Some are based on mindmap for task , Grantt
Some are outline + words + advanced excel, like Notion. But more limited .
GSheets need vpn and slowly.
I used most of apps, the Coda is the best.
Coda is more free and powerful for top used, others is second.
The most I like is Docs - Folders - Sections 3 levels structure. Wow ! It’s really smart .
You know, many web doc is just a doc, like WORD.
In Coda :
a Doc — a Disk
a folder ----a Folder
a section ---- a file
But no one can complete replace each others.
I often use those apps for efficiency and function.
But I think Coda will eliminate based on outline app, dynalist , transo, mubu …e.g.
2 Likes
I like brief, concise reasons that compel me to make changes. And while there’s certainly plenty of evidence that Coda can make Excel users very happy, I tend to see clients’ faces light up most when they see opportunities to do things they could never do [practically] before.
This is the magic of Coda; an architectural underpinning that puts new processes and information management ideas well within reach of business workers and professionals.
Most Excel users are Excel users because it already brings [better] order to their data, and in a friendly approach. They already believe - for the most part - that Excel is everything they need and a wonderful alternative to other less orderly and less friendly approaches. After all, what could be better than something that is awesome and works for everyone in their organization?
When I go into sales-mode for a Coda-base solution, I tend to accentuate the opportunity to advance business process and operational performance by demonstrating how a team can apply Coda using features and benefits that are near-impossible to do in Microsoft Excel, Google Sheets, Word, etc.
The simple ability to blend data from different sources into a single, well-structured document, or the ease with which lightweight processes can be integrated into the document using buttons and actions that are user-chummy all conspire to change the document game. It is the alchemy of activities and outcomes that truly set Coda apart from everything.
This is the blue ocean promise of Coda and made possible by Coda (as a force in the document business) and especially for Makers who want to differentiate their services to advance their work as employees or solution providers.
6 Likes
Hey @Paul_Danyliuk, I just couldn’t resist responding to this one. I am I continuing to ramp up my efforts to solve what I’m trying to do in Coda - in a few instances with your help, many thanks - in the last two weeks. As a non-dev, but “somewhat technical” manager in a software company, and also the decider of my team about which solution we will use to manage our processes, something hit me recently that seems partially relevant to this thread, and I think very relevant to those coming over from MS office:
I know this is a lot of the vision and messaging of Coda, but it is so much more than an Excel replacement, and so much more than a Doc.
I really think Coda is much more comparable to MS Access than Excel in fact.
For a non-advanced user of Excel - and I’m betting most of the active Excel-users in the community here are so good they could work as certified consultants charging $100’s by the hour, so this doesn’t apply to many of you 
- a lot of the Coda functionality that differentiates Coda from Excel, and where Coda works more as an app, is very challenging. Paul this post you wrote recently to help me:
You are providing a feature I’d really like in my attempts at creating hierarchies - making sure circular references are avoided, and keeping integrity within ancestral/descendant relationships. But this is very advanced, and I wonder how many non-developers or non-DB veterans could implement what you suggest quickly. I never got very far with MS Access or any other DB’s, but this type of stuff is not something I would have even thought to accomplish in Excel in the first place.
That said, there is great replication, with improvement, of Excel functionality in Coda all around. I am comfortable managing some lists of data I’ve moved from Excel. I’m doing things like quick-moving through sheets via the cursor on the keyboard, highlighting columns, adding rows, etc in Coda that are features I appreciated in Excel. And there are the improvements over Excel: Grouping is a great solution by the Coda team that is tons easier to use that Pivot Tables in Excel. One of my Coda successes is a simple tracker I set up to compare my various testing of the multitude of management apps out there. Using things like @mentions of rows in Rich Text columns to keep notes - tremendous! And I’ve found Coda does this tons better than, say, Notion or Air Table, apps I in fact track in this very Coda Doc!
I know Coda talks a lot in Marketing material and generally about being an Excel replacement. My main point is that, intended or not, the way Coda has developed, it’s so much more than Excel. But it does require advanced Excel skills, or more, to master. Comparing Coda to Excel I think is like comparing Excel itself to a table in Word.
Word table - can be replaced by Excel, but Excel offers so much more.
Excel - can be replaced by Coda, but Coda offers so much more.
And I do think “doc” can be a misnomer for what Coda is able to do. If you look at all major productivity apps - they have almost the identical structure as Coda, but across the entire app:
- Left-pane based hierarchy for major areas of the app - often called “Spaces” or “Folders”
- Some kind of list or grouping of types of entities or tasks, essentially Coda “rows”
- Dashboards, reports, etc. which equate with Table Views.
And a host of other thing Coda offers like integrations, automations, notifications, etc. etc.
I mean this as an accolade to Coda. Just like with the comparison with Excel being limited, the potential of Coda docs is such that they are capable of being full on Management Systems! Yet, you can easily use Coda to manage a simple list of clients, like in a spreadsheet, or write down some notes with good structure, like in a doc, and leave it at that. This is really a fabulously well-thought out tool than can handle all of this!
In closing, I wanted to add that I saw this come through yesterday:
It made a lot of sense to me. With the current stage of Coda’s development, I think there is degree of advanced DB/developer knowledge needed to accomplish things that other task/project management apps have built in. Fundamental Excel skills, or maybe even intermediate, are insufficient to accomplish most of the great stuff here in the community. I agree the value of apps being built by the Makers here in the community is such that there is monetary value to them. Along these lines, I will add that I greatly hope Coda does not ever go down the road of Atlassian and open up for 3rd party apps. I have struggled with most Jira apps I’ve used. I think Jira itself has suffered with the proliferation of these apps, as Atlassian has not taken on development of a lot of key features they are leaving to questionable-quality 3rd party developers.
Kudos to Coda, and my admiration to both of you @Paul_Danyliuk and @Bill_French for your adoption and mastery of this cutting edge piece of software. So much more than an Excel replacement!!
1 Like
Astute observation. Let’s revisit the past 32 years in personal databases …
dBASE II → dBASE III → dBASE IV → Clipper → FoxPro → MS Access → AirTable
What’s the common thread? Everyday business professionals can build stuff that helps them.
What’s the common operating ceiling? It’s all just data and some distractions that attempt to overcome the limitations for that data to participate at a document level.
1 Like
@Bill_French, always great to get your wise words!
Having just written a treatise on how challenging I find Coda, I have to say that all in all I am very impressed with how much I can do without any DB training. So just in case what I wrote seemed to indicate that Coda is “too hard” for non-technical types, in fact you are point out how much Coda has enabled. When you say:
This makes me think about my own experience with Coda. I think a good way to summarize objectively is that Coda in enabling so much that was previously unavailable to non-dev types, that it’s got me actually trying to do more than I am probably capable!
Cheers!
1 Like
Yet another astute comment.
Recall two decades ago when AI began to make waves. Fast forward to 2020 where analysts are still asking - when will AI actually work? Robotics has a similar bad wrap.
The reality is - AI (and robotics) is everywhere but it so well integrated and seamlessly applied that we don’t recognize it as “AI” per-se; rather - it’s simply “smart” products, services, etc.
The hidden side of AI is no different than some of the magical elements of Coda; we simply lack memory, context, and juxtaposition to measure just how advanced our document activities may actually be.
There are things in Coda that if I was able to demonstrate as late as 2005 would have likely landed me in Area 51 tagged as an alien from another world, or strapped to a plank and burned like a witch.
I often feel this way when jumping from server-side Javascript (my common integration language) to work on a data science project for a few weeks using Python. This is akin to switching from a Google Doc to Coda. Python is so far advanced in matters of data science and visualization that it’s extremely painful to switch back to javascript. But it does reset your level of appreciation for the underlying technology required to make your life and work so much better.
2 Likes
This is a great pitch. Just a heads up, @maria and I are doing a series of Crowdcasts on translating spreadsheets into Coda doc. Our first one was today on translating a Google Sheet of salary data into a interactive Coda doc.
I have personally developed in every one of those tools mentioned (dBase II on a CP/M machine). I remember the “good old days” of the dot prompt.
Having said that, I find it surprising to suggest the inclusion of Coda in that list – even as it includes AirTable. The first six have robust (for their time) and accessible scripting abilities that go well-beyond what Coda has done. However, Coda is absolutely an improvement on spreadsheet and macros – mostly. In my testing, things begin to really slow down when a table has more than a few thousand rows.
Frankly, while I have much more love for Coda than AirTable, the Coda API experience pales in comparsion largely due to the super sluggishness. It shouldn’t take nearly five seconds (from API call to browser rendering) to update (not upsert, which is even slower) a single column in a row. Airtable is much much faster. And the current rate-limiting is unacceptable for any serious real-time integration with an underlying data source (“source of truth”) that is not Coda. I asked customer support for an understanding of their rate-limiting policy, got a request the next day for clarification, which I gave, and haven’t heard back since. Yes, I’m a PRO user.
So currently I have a frustrated relationship with Coda. There is a lot of potential, but until the API responsiveness improves (and large rich-text values are allowed in cells without causing the rendered row to become giant [yes, I’ve tested available workarounds]), its use will be limited for me and my company. Moreover, several times during testing I’ve had stale data returned from API queries until I refreshed the page of the browser where rows had been deleted – that was scary.
I have high hopes for Coda and I have committed to them already in several ways, but, from my perspective, they have work to do to be considered a database replacement.
2 Likes
It’s great to see dBASE alum in this community. They were the good’ol days - pre-ethernet, times were tough but we got the job done using a very small fraction of the resources that adorn our pockets today. My, how times have changed.
When I first introduced LapLink to NASA, even IBM engineers were astounded at the transmission speeds we had achieved - a whopping 128k bits-per-second. Today, our cell phones quietly move data all day long at many times that rate - even while we shop, or play, or work - we give it no thought. Indeed, the good’ol days are still here magnified thousands of times - we just don’t see it.
You are surprised because you are conflating business requirements of the final two decades of the previous century with predominant business requirements of the third decade of this century. 
Times have changed, and specifically computing architectures have changed. These are not insignificant shifts in how we work and most important - how work is distributed.
Coda is not a database; never was and probably never will be. Sure, you can do some databasey things with it, but it should not be cast in the same light as dBASE was, or for that matter what MongoDB is, or what Firebase is. Imagine comparing iPhone 12 to an MP3 player (circa 1992); it’s a silly notion. These are vastly different products designed for times that were vastly different in many ways.
Coda is a reimagination of the document; it’s a document platform for today (and perhaps tomorrow). It addresses business requirements at the edge of operational process. It is not ideal as a central datastore nor should it be considered as an inner core data resource. It is vastly useful as a place to federate information and it can play a role in data aggregation to support inner-most operational requirements.
No debate here. It needs to improve, but a traditional RESTful API is not the path to performance.
Indeed, and why they need to allow (or adopt) sockets-layer data exchange. Imagine if we could simply plug in PubNub or Firebase into a Coda document. Document-centric applications (at the edge) could enjoy millisecond-level performance with actual database technology.
5 Likes
@Federico_Stefanato, you’re welcome. I just call it as I see it.
While there’s nothing inherently wrong with pushing any technology to its limits, it’s important to understand the motivation and the requirements while paying close attention to the topography of the business requirements. And I think there’s an equal duty of the tech vendors to anticipate how makers and consumers will react to their platforms and possible misinterpretations of fitness.
Three distinct aspects of modern computing architectures should be top of mind as you continue to create what I believe is a revolutionary transition to a new definition of modern documents. If you’re going to make claims that documents must – at their core – embrace data management, I believe you must also carefully consider how to embrace these four architectural underpinnings.
-
Asynchronous, frictionless, and seamless data interchange - not simply with other platforms, but specific databases and network protocols. It should be as easy to integrate Coda documents with Dropbox as it is with arbitrary storage and communications platforms.
-
Objectify every aspect of a document - every part of a Coda document should be exposed in the Coda API; we need pervasive capacity to access and create document objects programatically.
-
Pervasive event architecture - it should be as easy to call a webhook in any information change context as it is for Coda to hear and react to webhook calls.
-
Scripting agility - vast libraries and script engines are commonly available today and the ability to blend the power of Python (for example) into Coda solutions enhance the promise of a bright future for a document reimagination.
@Joey_Serio also makes a very important point where he indicates that “rate-limiting is unacceptable for any serious real-time integration with an underlying data source (“source of truth”) that is not Coda”. His argument has vectors into three of the four points I made here and the most important words in his assertion are “…that is not Coda”. Timely and informed decisions that factor in external information – arguably, one of the key values of any modern information solution - is vastly eroded when you fail to meet this requirement.
His point survives a key test - remove the term “real-time” from his statement; the requirement is unchanged. In fact, I would argue that the use of the term “real-time” is redundant; we live in an always-on, always-accurate API economy. Real-time information has now become basic data hygiene.
5 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.