When approaching different entities for demonstration purposes, there has been a list of subjects and possible works for which this publishing application is suitable:
Privately the publishing application can be used e.g. for preparation of writings to be published elsewhere (e.g. online or in a print publication), for storing online coursework assignment responses and associated images, for planning what to write to email contacts, for coordinating online discussions on forums etc.
List of projects. After logging in, the Fresh section of the project list always opens, listing the projects that the user has classified as current or such. From the same view, you can access the Settings modal window, where you can make user-specific settings from image catalog to the configuration of external services. The function for logging out is placed exclusively in this project list view. The sorting labels fresh, past and forgotten can be taken to mean that wherever the project is placed, the word "forgotten" does not have to mean that something has now been definitively left in a position where it is no longer used and that it may not even be important and, who knows, even if one wants to forget it. Later on, it may be promoted back to the fresh level, e.g. if one feels like it, or left at the past level for a while, in case there is time for further contemplating or preparation at some point.
Project Management. This view contains navigation links/buttons to all views/modal windows relevant to the project, from the beginning of writing to fine-tuning the final work, from backup functionality to selecting image catalogs, and from asset management to search functions. Writings are accessed by creating a collection of writings and selecting the corresponding link that takes to the text editing view. Yhdestä projektista voi johtaa useita, yhteisesti kuvakatalogeja käyttäviä teoksia kuten esim. erikielisiä sellaisia.
Text editing. The basic elements of a writing are the textual parts of it (some of which are fully optional) and the 'particulars' that can be included to the writing (are initially just attached to it without being placed in a specific position). There are many more types of these attachable particulars than just images. It is also possible to include another writing in an writing. In addition to the text formatting functions, the text editor menus offer a variety of helpers etc.
Writing fine-tuning. From a productivity point of view, it would not necessarily be appropriate for a piece of writing to always look exactly as the end result appears, as the thinking process is different, when attention to styling takes up a slice of the thinking time. This is why the fine-tuning of the essence of the writing and the stylization of the elements included in the writing are done in a separate view. Saves time and mouse movements, also. The final appearance of the writing can be viewed in the preview panel or by opening the part of the work where the writing is visible in another tab or browser window.
Special pages of the work and work-specific adjustments. Even a small adjustment can have a big impact, as can be seen for example in how a single adjustment can transform a work started as a blog into a work having a hierarchial table of contents like in a book. Other work-specific adjustments include those that prepare the content of the front page of the work (edited elsewhere) and minor adjustments from language selection to caching and from setting publicity to setting page width. On the front page of a work, before and after collections of writings, there may be links to "special pages", which could be e.g. an Appendix, Glossary or whatever you want them to be. On special pages, images from image catalogs can be placed directly to the text.
Browsing the image catalogs. There can be a lot of images per project, so it is largely up to the user to ensure that they are easy to find and use. Moving images from one image catalog or image container to another does not affect the visibility of the images in the writings, but for the production of writings, it is easier to find images when the image catalogs and containers are at least named well. There is not yet a search function that will bring up any image when you ask for it. A very useful feature will be the possibility to see directly if and where an image has been used, i.e. in the image browse view, each image will have direct links to the writings etc. where the images have been used. Several "triggers" are set to react to changes in browser window's width to change how many images and in which size can fit on a single row of images (useful in multi-window operating systems). Naturally, images can also be viewed at their largest size. Image catalogs are selected for use on a project-by-project basis in the project management view, and image catalogs are created in the Settings modal of the project list view.
There are no restrictions on how many different views of the user interface can be visible in the browser at the same time. They can be ordered in tabs or in separate windows. A large monitor undoubtedly offers the most useful user experience, but the interface views are adaptable to use even on a smartphone. As a side note, to improve usability, it is advisable to install a general-purpose add-on on the browser you are using, which can be used, for example, to move between different tabs with a fancy mouse gesture.
To be honest, there is no particular reason to take the names of user interface views as something that would easily explain what they mean, what they are used for etc. For example, the word "adequates" does not really tell you anything until you have used the view in question and realised that "ah, this is what it's all about". Thus, these are here for some sort of "explanatory necessity" to create an impression of the scope of the service, etc.
The service can be partitioned in many different ways for purposes where there is a significant increase in usage or just a desire to separate the public and private sides, for example, to use different servers.
If there is anything to be understood from these descriptions, it might be that the publication service can be "chopped up" in many different ways, so that different functionality can be assigned to different servers, so that, for example, uploading images to the service (and scaling them to different sizes at the same time) would not place a load on the same server that is used to display the finished works. Reliability can be increased by multiplying the number of servers performing a given functionality and letting the load balancing component decide which one is used at any given time. Database servers and files can be replicated to ensure that even a hardware failure does not interrupt the service, because all data and files would be continuously at least duplicated before the hardware failure.
Other noteworthy possibilities include: a network file system, i.e. different servers can share certain files such as user's images; synchronisation of caching of data retrieved from a database between servers. This is of course only if more than one server is used. The use of more than one server is not necessary at all, i.e. everything needed such as the database management system, image files and the application server can be located on a single server. It is always possible to change resources such as memory, disk space and time slots on the processor (vCPU).
Load balancing of server hardware and software will not be fully utilized if the Linux server that first receives the incoming signals is configured to be highly restrictive in the outbound bandwidth. This is better explained in the writing "A word about limiting data transfer costs and visitor traffic".
From a content production perspective, the publishing application has been developed on a "big screen and rollerball computers with physical keyboard first" basis, but time is sometimes spent ensuring that tablets and laptops with a sufficiently high resolution and size could also be suitable devices. For browsers, it seem to be easy to achieve an equal level of functionality, so the assumption has been taken that functionality is good even on more exotic ones, provided that it has been verified with the most common browsers.
The publishing application functions well and equally on at least Edge, Firefox, Chrome and Safari.
The Samsung Galaxy Tab S7 having a 11-inch screen has different dimensions to the iPad, which means that not all kinds of elements can fit side by side in portrait mode, but on the other hand the publishing interface adapts quickly to landscape mode. Also, using a browser in fullscreen always gives a bit more space, which is useful when using a laptop such as the ASUS ZenBook in all its 14-inch.
It has been tried to use the publishing application on a Sony Xperia Z3 Compact Tablet, which has only moderate power and a screen size of only 8 inches. Technically the publishing service works normally on it, but the different parts of a view of the user interface have to be placed one above another in accordance with the principles of responsive user interface design, so there's quite a bit scrolling required.
At some point, the publishing applicationmight get developed to optimise the user interface views more finely in terms of space usage, but a few dozen other features might be prioritised before that.
As for controllers, the Samsung Stylus Pen is very handy and recommended for compatible devices, offering not only very good sensitivity and accuracy, but also the hover feature that Apple Pencil lacks.
The instructions may refer to the using of the Ctrl key (Windows) in certain situations, but the Meta key (Mac) can also be used to access those functionalities.
When using or buying a laptop computer, it is recommended that it should have arrow buttons that aren't kind of squeezed to fit in their place as otherwise one needs to consciously think about using them, motor movement slows down and and the flow of thought gets interrupted unnecessarily.