Here at Paperbits, we believe that in the process of creating and publishing web content the participants should play the role they are good at: authors - write, designers - take care of look and feel and developers implement the behavior.
If writers begin to add CSS styles to the content, it often leads to significant maintenance issues and silly bugs that stay unnoticed for a long time. In opposite, if a developer works with a professional designer to add required styles, they ensure the consistency in user experience and perception while keeping the content maintainable.
However, to make it possible, the content (presentation) has to be separated from the code (implementation). Those who once came to the same conclusion most likely know about Markdown, which is fantastic when you need to process simple hypertext. Though, when it comes to complex structures like responsive grids, one may need to look for other techniques.
Apparently, every other website theme brings its unique styles and markup. For instance, centering the text with Twitter Bootstrap is achieved by adding "text-center" class, whereas "Semantic UI" framework uses "center". Keeping ourselves from binding to code introduced by a particular theme, we may overcome this by presenting the content in the form of intentions (for our platform we choose to express them in JSON):
Using the format like this, we can build an adapter for transpiling our content literally for any theme or platform. It will add required Bootstrap's "text-center" or ignore the alignment instruction if the publishing target does not support it.
The story doesn't end here. Similarly, we can add annotations for other adapters, i.e., authoring tools that support features like commenting on selected text or bookmarking it. Besides that, some JSON-based storages like Google Firebase may dispatch events on any node change, thereby, allowing us to implement real-time collaboration tools in our editors.
Another fundamental approach we stick to is keeping our code executable in both browser and server. That is why we're big fans of frameworks like Angular, Vue JS and React who provide server-side rendering out of the box. Precisely same components, once rendered (by our Express middleware or pre-generated as a static website by our Publisher), are picked up by the browser to continue running on the client without users knowing about it.
In many cases, the temporary absence of network connection should not stop authors from working on their content. Modern browser features like Service workers and IndexedDB allow minimizing dependency on the network (and reducing traffic between client and server) and, of course, Paperbits takes advantage of this technology too by including offline-first concept it into its design.
Website builders like Wix or PageCloud use absolute positioning. We believe it's not a scalable and convenient approach since it often requires you to reposition, realign and resize widgets depending on form factor. That is, most likely, the reason why those two builders allow only two views ("desktop" and "mobile") - they want to minimize users' frustration.
The problem with absolute positioning is that it's not natural for the Web, therefore frameworks like Twitter Bootstrap and Semantic UI rely on responsive breakpoints rather than specific coordinates and sizes. This approach allows more complex layout flows from screen to screen, so websites built with this framework look most optimal on devices of any size. No wonder, the same method lies in the core of Paperbits tools and themes.
Copyright © 2020 Paperbits LLC. All rights reserved.