CONCEPTS > Editing in Microsoft Word vs. Editing in web-native environments like Tallyfy

This article helps bridge and explain the gap between what a lot of people are used to doing (editing in Word) vs. editing content in Tallyfy, which natively uses HTML. There's an important term to introduce here - Web-native content vs. Word content.

The most important difference is that web-native content is authored in HTML - which is an open standard built for the internet. These days - almost all content will eventually end up being viewed in a web browser, not in Microsoft Word or a PDF viewer. The days when concepts like "pages" and "page breaks" were important only applied to documents you were printing, on a physical printer. Those days are long gone. People now view, share and interact with content (which wasn't possible in paper) on many devices - such as smartphones, tablets and desktop computers.

Browsers, mobile devices, and even screen-readers can interpret and display web-native content in many form-factors. That extends to form-factors beyond just a big or small screen (like a phone or tablet) - and includes braille readers, voice dictation, and many more enhancements that have yet to appear in future.

Word processors like Microsoft Word were created before the internet and were built for printed documents that had to fit into a specific size of paper - which varies in size from place to place.

This is a list of differences in approach for web-native documents vs. editing and using Microsoft Word documents.

All content has to work on all devices - with all background colors, in all sizes

People don't print stuff anymore. Everything you type must be automatically ready to consume on all devices - which includes browsers, tablets and smartphones. This means the idea of thinking in "pages" is fundamentally incorrect.
For a digital-first, mobile-first world - you need to think "web-first" not Word-first. That means adopting a simpler, content-first approach with a massively reduced intent to customize formatting and styling. Excessive formatting simply doesn't work for multiple devices, multiple form-factors and for people who read content in different ways. For example - many apps have something called "dark-mode" which can help reduce eye strain. As people study the problem of eye strain, stress and related subjects in future - hard-formatting your content to work on a white background is a bad idea.

Web-native content separates styling from content

The web uses HTML to describe content and how it's structured. CSS (stylesheets) are used separately to describe how elements of that content actually look - on various devices. You can focus on the content, because stylesheets are going to handle styling for you.
A consistent style encourages a brand-compliant, consistent look and feel - across all documents. You need to avoid using styles as much as possible, no matter how tempting it is!
Needless formatting is a huge waste of time - which costs both the editor and the user of the document a lot of frustration and manual work. There's a body of studies in the academic domain about this - like this one. Intuitively - just imagine how much time it takes someone to manually change the formatting of words and sentences, whether it's multiple font-colors, multiple font-sizes or multiple embellishments like underlines, italics, bold or margin or paragraph indentations or even worse - multiple fonts. Just don't do it.

Web-native templates in Tallyfy discourage unlimited copies of the same Office document

Templates in Tallyfy are like a recipe or template you create once. Learn more about them here.
If you make a document template - you mark sections of it as editable using form fields. All the rest of it is non-editable. This means that if someone wants to "fork" a copy of a document - they do it the right way. The parts that are editable remain editable, but everything else remains consistent and read-only.
Eliminating "copies" of the same document prevents out-dated copies circulating in unknown places.
Eliminating "copies" of the same document also eliminates the varied and often inconsistent file naming conventions that people use to name their "own version" of a document.

Web-native lets you include one block of content in many places

Imagine if 50 documents have the same three paragraphs. Now imagine if we had to change those three paragraphs. How do you avoid going through 50 documents, one-by-one, manually - to edit a snippet of re-usable content?

Tallyfy has a native feature called a snippet - which enables you to create a static block of content in one place and then use it anywhere you like. If there's any changes to that static block - the latest version goes live instantly, wherever it's referenced.

Web-native content can use browser-native editing tools

If you want to check spelling, grammar and much more - you're not stuck with what Word offers. There's tons of spelling and grammar plugins that work natively with browser text editors like Tallyfy. Apps like Grammarly for example - help you improve your grammar along with basic checks like spelling, etc.

Web-native content is inherently shareable

Natively - a template or content you author in Tallyfy is shareable by just sending someone a link. We need to end the practice of attaching large documents and files in emails - it's just pure waste.

Web-native content has accessibility and vendor support baked in

There's a lot more people building products that use or interface with HTML than with Microsoft Word.
Not everyone uses Microsoft Office or Word. Sending someone an Office document does not automatically guarantee they can open it.
HTML is an open standard, ensuring inter-operability and future-proof migration between platforms. That includes systems like search engines that need to index content for classification and search.
Most companies and content require accessibility for content - often to specific WCAG standards. Entities like the UK Government have actually made it illegal to have non-accessible documents. Lots more governments and public sector bodies are following suit. Using HTML is a much simpler way to ensure compliance.
File sizes for simple HTML documents are a lot smaller than what word processors produce - saving a lot of money and resources in storage, backup and transfer costs:

Tallyfy only supports plain-text copy and paste from Word

You can copy and paste text from Word or other apps into Tallyfy, but we strip all the extra tags and sludge that Word generates, including formatting. This means that once it's pasted in - you may need to add in line-breaks, a little basic formatting and semantic headings as you see fit.

This ensures that we don't get into all the problems with Word HTML. In fact - Word HTML is so famously bad - there's entire tools called "cleaners" that exist specifically to remove the sludge and strip the bloated markup generated by Word:

Word documents vs. Tallyfy - A summary

We hope that helps. HTML is overall - a simpler, better, future-proof, vendor-agnostic, mobile-ready and more open way to author and publish content.

Yes - you will lose some fancy formatting you used to have in Microsoft Word - but ask yourself, was it strictly critical to have that formatting in your document in the first place?