As a first suggestion, I would really love a public Roadmap and a more complete changelog on a distinct page.
This would allow me to work on my documents with a perspective of changes if needed.
Actually I sometimes walk a bit in the dark, even if Coda already have everything I need, and thanks to the awesome Coda team, they always give me answers.
A Roadmap would be great
Iād love to know from you both what your ideal roadmap would look like. Do you want the nitty gritty details, or just bigger thoughts around features? Share your wishlist!
Iām a big fan of the technical details, because it helps me think about whatās possible and whatās difficult. It also helps me improve the performance of my own documents. Iām often working with large tables, so knowing what similar functions perform better does make a difference (similar to the VLookup/Index-Match debate!).
But even knowing whatās on the horizon for next week vs. next month helps me plan out what documents I want to build in Coda next. Weāve a number of Google Sheets at the breaking point that I would love to bring into Coda, save for auto-import/export or cross-doc features, and knowing what could come next helps me plan a little more.
Yes, I also think like that. I like details in a changelog because there are always many little improvements and bug fixes that would help me a lot.
And on a Roadmap I both need big plans, to have a kind of motivation along the use of a product and also to plan changes, and short planned improvements that I know would save me some time and problems.
Here is an example which I find absolutely gorgeous : https://community.amazingmarvin.com/roadmap
Their changelog is always filled with new updates and they have 3 levels of roadmap scheduling. By the way, I recommend the use of this website for personal task managing and procrastination beating ^^
Great feedback @tomavatars@chris_homburger - really appreciate it! Will chat with our product team about the best way to implement a version of what youāre describing. Weāve been moving to a more regular cadence of āRelease Notesā which will highlight big features updates and smaller refinements (how have those worked for you?), but definitely want to create a more forward-looking view for our customers.
@evan Those are good, but as said above, add more info! Iāve been checking in quite often but seldom see changes.
Why not use the power of Coda to meet everyoneās wishes?
You could have a checkbox to only show āMajor Feature Releasesā. When checked, this would display about what you have displayed in that doc right now. When unchecked, it could also display each change, sort of like a changelog.
Add in future changes into the same table, and make them distinct. Mabe group by approximate release on the left? You could use this to encourage community participation in the features that you are unsure of how to solve, maybe by linking to a thread on that feature here.
Iām a fan of themes versus specifics. It will be helpful to know the product direction and the types of problems you are currently working on versus a monolithic backlog.
Iām a bit lost because I love Coda, but your concurrency are very quick to add awesome features to their products : see Notion and their big 2.0 version which is definitely your main opponent and as I already told here, Airtable.
I donāt really have an idea of where you are leading with Coda. There are many fields that needs improvements (both UI and UX) and as beta testers and in my case, everyday user, I would really love to know why I should keep using Coda instead of migrating to other products.
Again, Iām very sorry for this commentary, but I feel that Iām slowly loosing my hype with Coda
Nothing makes me happier than talking roadmap with our enthusiastic users . Just did a fun meetup in NY with a few of you and got great reactions and feedback to some of our upcoming demos.
Weāve heard your feedback on a more public roadmap and are discussing a few patterns for how and when to do it. Stay tuned. In the meantime, I thought I could share a few thoughts here.
As you know, we have a lofty vision that people can build docs as powerful as apps. As weāre in our Beta stage, weāre very interested in listening and hearing what you think is most important - we watch this forum in particular quite carefully.
To answer your question, we are currently working on a mix of large shape-shifting features as well as a long list of the fixes and refinements that seem small individually but large in aggregate. On the larger side, weāre actively working on two primary features. You may have heard about a concept we call cross-doc, where docs can connect to other docs. Weāve also heard a ton of feedback about getting data in and out of Coda so weāre working on an API to get data in and out of Coda (some of you are probably beta-testing it right now). These are large initiatives, and weāre taking the time to get them right.
Weāre also knocking out some of the smaller but impactful user-requested features. Last month we focused on launching the new gallery and rounding out tables with āminimalistā controls, wrapping text in column headers, selective sharing, and a bunch of international fixes. For this month: we heard you wanted a better writing experience so youāll notice a new H3 format in the toolbar with indent, spellcheck, and markdown following close behind. All the while, weāre continually sanding down cornersć¼polishing our interfaces and squashing bugs.
In terms of the next-up ideas, weāve built out some (pretty awesome) designs for our upcoming mobile work, thinking about forms and buttons, and also where to take API and cross-doc next. Weād love to hear your ideas on other ways to make docs as powerful as apps.
Thank you very much @shishir for those awesome projections!
Cross doc and api will be fantastic!
My personal feeling is that there should be a way to make views more customisable. Iām especially thinking of card views as I already told in another thread. So overall polishing, polishing of views and customisation is for me the high priority.
But all the smaller additions you told us are great! Markdown ? Yay !
And mobile app is also very very exciting.
Actually, mobile app is very much needed
I donāt want to write ideas in evernote anymore.
It doesnāt make sense as all my protects are in Coda.
So Iām really looking forward a mobile app! And very curious of what you already designed!!!
One last thing, Iām projecting on using Coda as a public workspace, to let people view the process and advancement of a video game production.
Iām thinking of using Coda rather artistically, as an artist would use a sketchbook to prepare paintings. For a video game process, it would be a mix of researches and brainstorm canvas (need free layout to make things fun!), design documents and backlog/sprints.
I believe Coda has a real power for fancy public workspace and I canāt wait to be able to do this!!
@tomavatars I love this idea of a public workspace. Since Kevin Rose shared his development process of his Oak App in a facebook group with everyone who was interested, Iām obsessed with the idea of giving real and lifeinsights of a production/development/design process. But instead of āposting updatesā you could just let people visit your planning & controlling tool.
This is what I want to do, let people visit the whole Coda space, from a link in the Steam page.
The design sections would be shared as well.
Updates would be referenced in the Steam page by the game updates itself. And a section in coda would be filled with different views corresponding to updates. This is also why I need bookmarks.
@tomavatars Awesome idea. I see what you described happening a lot with blockchain/cryptocurrency projects where the developers will open up their internal Slack channels to the public. This way you can see all the issues, bugs, and features being worked on by the core team. Additionally, you can follow commits and pull requests on GitHub, but this is not as freeform as a document surface.
More importantly, getting creators to share their projects has multiple benefits:
Public Knowledge - Your video game project would be like contributing to Wikipedia, and since itās public, anyone would be able to @reference that project to use in their doc. Letās say the name of your game is āTomās Adventures.ā One could then write something like @Tom's Adventures to get the full record of your game or =[Tom's Adventures].[Release Date] to get a specific field about your game. (Excel is rolling out new data types this year which is similar to this concept).
Open Source - More innovation comes from projects that are shared to the public with multiple contributors.
API - Building off of public knowledge, creating an endpoint for your data makes it easier for others to incorporate your knowledge and resources into their own projects (hint hint: Zapier integration) .
I was recently invited to the community (thanks!) and, having been closely involved with public roadmap development for G Suite, will humbly offer my $0.02.
To begin, Iād like to share one of my favorite memes with the Coda team: āYou canāt please everyone. Youāre not a Nutella jar.ā This certainly resonated with me over the course of many roadmap iterations to meet the needs of our customer base. What follows is more my POV than where we were with the roadmap when I left Google.
A couple of dimensions already mentioned on this thread are timing and level of detail, and I believe theyāre interrelated. That is to say, the closer a feature set moves toward release, the less likelihood of significant change by the engineering team, and hence more detail can be shared with customers. Letās see what this might look like in practice (i.e. using a dated, already public Google example).
Assume three levels of scheduling for features: short-term (current quarter or next), long-term (2-3 quarters away), and directional (no timing). As customers need to understand where youāre planning to invest, posit a list of themes - or better yet, use cases - in the directional bucket (e.g. eDiscovery support will be added for Google Drive).
As scoping for a particular use case proceeds and it moves from directional to long-term, your quarterly roadmap update will expand to include the components of eDiscovery to be supported (e.g. retention, legal hold, export). As development continues and you gain feedback from trusted testers, the feature set moves from long-term to short-term and the next roadmap update includes screenshots showing UI/UX attributes. Considering the competition, the nitty gritty details only come post-release in Help Center articles.
While Coda enjoys the luxury of beta status today, eventually it will launch. From that point forward, your product roadmap (for all intents and purposes) IS your product. And I canāt wait to see where you take it. Keep up the great work!