4 ms·

> Word 99% of uses can be trivially replaced by plain text, Markdown, or Org. For the others you probably want a real typesetting system anyway, so Word would

> Word 99% of uses can be trivially replaced by plain text, Markdown, or Org. For the others you probably want a real typesetting system anyway, so Word would still not be appropriate. > Excel If you're at a point where it feels appropriate to use vendor-specific spreadsheet features then you have already outgrown by far spreadsheets. It's probably both simpler and more maintainable to decouple your data from your code by using a database (even SQLite, if you still want to pass files around) and/or a scripting language instead.

sl1ck731 7y ago
My main use cases for MS Word is RFP responses, architecture descriptions, requirement definitions. Neither of those options would satisfy that an an inter-operable way with the rest of the relevant people. I guess if you're purely writing code all day then I could understand never needing productivity suites, but I assume most roles have either customer-facing or organizational interactions beyond consuming Jira tickets. Using a database and scripting is overkill for 90% of things and is just over-engineering a problem that spreadsheets already solves well and are understood by the people who are meant to read them.
- Nullabillity 7y ago
  > RFP responses This might as well just be a PDF. The source format shouldn't matter if the recipient is just going to read it. > architecture descriptions, requirement definitions A hierarchical plain text document (biasing towards Org if you want internal links) would satisfy the same use case and play much better with source control. > Using a database and scripting is overkill for 90% of things and is just over-engineering a problem that spreadsheets already solves well and are understood by the people who are meant to read them. It's not a binary. I don't particularly like Python or SQLite, but I'd take a couple of quick and dirty Python+SQLite scripts over a bunch of unstructured spreadsheets any day.
  - sl1ck731 7y ago
    All of those things are collaborative. Project managers aren't going to learn how to edit those documents. Sales guys aren't going to start including their bits with markdown and the marketing team isn't going to fiddle with images in markdown. Its a solved problem, I don't see why you would want to engineer so much around such simple tasks for the only reason seemingly to be not using Microsoft.
    - Nullabillity 7y ago
      > All of those things are collaborative. Indeed. So why on earth would you pay for tools that make all version control systems barf? > Project managers aren't going to learn how to edit those documents. Sales guys aren't going to start including their bits with markdown and the marketing team isn't going to fiddle with images in markdown. It's not that hard. Ask a random nine-year-old to come up with a formatting syntax and they'd likely come up with something with a canny resemblence Org. > Its a solved problem, I don't see why you would want to engineer so much around such simple tasks for the only reason seemingly to be not using Microsoft. Why would you use a overcomplicated WYSIWYG editor to make a few things bold and add a list? Why would you pay for that miserable experience?
      - sl1ck731 7y ago
        Ask a random nine-year-old to create a Word document. If triviality is your concern, everyone is at some point required to learn Word. It is quite literally one of the first software anyone in the US is introduced to. You are absolutely guaranteed to encounter it at some point K-12 or and in college. Random markdown syntax and git, not so much. The idea that you are going to dictate how you communicate to and share with the rest of your organization (sales, marketing, compliance, legal) because of an affinity for software related tooling is laughable.
vetinari 7y ago
> 99% of uses can be trivially replaced by plain text, Markdown, or Org. For organizing content, yes. For communicating with others, no. For example, we are using Word documents on the edge, when communicating externally. We cannot expect them to access our internal wiki, and neither we want them to. > If you're at a point where it feels appropriate to use vendor-specific spreadsheet features then you have already outgrown by far spreadsheets. It's probably both simpler and more maintainable to decouple your data from your code by using a database (even SQLite, if you still want to pass files around) and/or a scripting language instead. Sure, if you have the budget to do it right. The excel-based solutions are often done so, because everyone has excel anyway, and the one coming with that has no budget or buy-in to procure the server-based solution.
- Nullabillity 7y ago
  > For organizing content, yes. For communicating with others, no. For example, we are using Word documents on the edge, when communicating externally. We cannot expect them to access our internal wiki, and neither we want them to. You can't just copy the Markdown (or whatever format your wiki uses)? Most of them read fine as plain text. > Sure, if you have the budget to do it right. The excel-based solutions are often done so, because everyone has excel anyway, and the one coming with that has no budget or buy-in to procure the server-based solution. You don't need a server to use SQL (see: SQLite, H2, Derby, or even Access).
  - vetinari 7y ago
    > You can't just copy the Markdown (or whatever format your wiki uses)? Most of them read fine as plain text. In the process you will lose links, images, etc. Additional complication is, if these are multiple wiki pages, you have to save each separately. You are not going to explain that to normal users. (Ever explained to a user, why he cannot attach word documents into bug tracker, but he is supposed to put the content of the document right into the appropriate text fields? Not fun). > You don't need a server to use SQL (see: SQLite, H2, Derby, or even Access). The reason why Access is not being used is, that it is not a part of the most sold Office SKUs (neither SoHo nor Pro). In fact, I just tried to quickly find out, which are the the non-365 SKUs that do include Access, and I failed. And again, normal users are not going to use sqlite, h2 or derby without having some kind of forms frontend. Access would be ok, but it is not accessible to everyone who has Excel anyway.

sl1ck731 7y ago

My main use cases for MS Word is RFP responses, architecture descriptions, requirement definitions. Neither of those options would satisfy that an an inter-operable way with the rest of the relevant people. I guess if you're purely writing code all day then I could understand never needing productivity suites, but I assume most roles have either customer-facing or organizational interactions beyond consuming Jira tickets. Using a database and scripting is overkill for 90% of things and is just over-engineering a problem that spreadsheets already solves well and are understood by the people who are meant to read them.

Nullabillity 7y ago
> RFP responses This might as well just be a PDF. The source format shouldn't matter if the recipient is just going to read it. > architecture descriptions, requirement definitions A hierarchical plain text document (biasing towards Org if you want internal links) would satisfy the same use case and play much better with source control. > Using a database and scripting is overkill for 90% of things and is just over-engineering a problem that spreadsheets already solves well and are understood by the people who are meant to read them. It's not a binary. I don't particularly like Python or SQLite, but I'd take a couple of quick and dirty Python+SQLite scripts over a bunch of unstructured spreadsheets any day.
- sl1ck731 7y ago
  All of those things are collaborative. Project managers aren't going to learn how to edit those documents. Sales guys aren't going to start including their bits with markdown and the marketing team isn't going to fiddle with images in markdown. Its a solved problem, I don't see why you would want to engineer so much around such simple tasks for the only reason seemingly to be not using Microsoft.
  - Nullabillity 7y ago
    > All of those things are collaborative. Indeed. So why on earth would you pay for tools that make all version control systems barf? > Project managers aren't going to learn how to edit those documents. Sales guys aren't going to start including their bits with markdown and the marketing team isn't going to fiddle with images in markdown. It's not that hard. Ask a random nine-year-old to come up with a formatting syntax and they'd likely come up with something with a canny resemblence Org. > Its a solved problem, I don't see why you would want to engineer so much around such simple tasks for the only reason seemingly to be not using Microsoft. Why would you use a overcomplicated WYSIWYG editor to make a few things bold and add a list? Why would you pay for that miserable experience?
    - sl1ck731 7y ago
      Ask a random nine-year-old to create a Word document. If triviality is your concern, everyone is at some point required to learn Word. It is quite literally one of the first software anyone in the US is introduced to. You are absolutely guaranteed to encounter it at some point K-12 or and in college. Random markdown syntax and git, not so much. The idea that you are going to dictate how you communicate to and share with the rest of your organization (sales, marketing, compliance, legal) because of an affinity for software related tooling is laughable.

vetinari 7y ago

> 99% of uses can be trivially replaced by plain text, Markdown, or Org. For organizing content, yes. For communicating with others, no. For example, we are using Word documents on the edge, when communicating externally. We cannot expect them to access our internal wiki, and neither we want them to. > If you're at a point where it feels appropriate to use vendor-specific spreadsheet features then you have already outgrown by far spreadsheets. It's probably both simpler and more maintainable to decouple your data from your code by using a database (even SQLite, if you still want to pass files around) and/or a scripting language instead. Sure, if you have the budget to do it right. The excel-based solutions are often done so, because everyone has excel anyway, and the one coming with that has no budget or buy-in to procure the server-based solution.

Nullabillity 7y ago
> For organizing content, yes. For communicating with others, no. For example, we are using Word documents on the edge, when communicating externally. We cannot expect them to access our internal wiki, and neither we want them to. You can't just copy the Markdown (or whatever format your wiki uses)? Most of them read fine as plain text. > Sure, if you have the budget to do it right. The excel-based solutions are often done so, because everyone has excel anyway, and the one coming with that has no budget or buy-in to procure the server-based solution. You don't need a server to use SQL (see: SQLite, H2, Derby, or even Access).
- vetinari 7y ago
  > You can't just copy the Markdown (or whatever format your wiki uses)? Most of them read fine as plain text. In the process you will lose links, images, etc. Additional complication is, if these are multiple wiki pages, you have to save each separately. You are not going to explain that to normal users. (Ever explained to a user, why he cannot attach word documents into bug tracker, but he is supposed to put the content of the document right into the appropriate text fields? Not fun). > You don't need a server to use SQL (see: SQLite, H2, Derby, or even Access). The reason why Access is not being used is, that it is not a part of the most sold Office SKUs (neither SoHo nor Pro). In fact, I just tried to quickly find out, which are the the non-365 SKUs that do include Access, and I failed. And again, normal users are not going to use sqlite, h2 or derby without having some kind of forms frontend. Access would be ok, but it is not accessible to everyone who has Excel anyway.