BookStack
BookStack copied to clipboard
BookStackApp
Add Text size option in the WYSIWYG editor
Describe the feature you'd like Just like in a Word document, we should have the option to change the text / font size of the words.
Describe the benefits this feature would bring to BookStack users It would expand the WYSIWYG editor a lot, especially for people like me who are used to Word or Google Docs.
Additional context I honestly don't know why it hasn't been implemented already. Must-have feature in any WYSIWYG editor!
Hi @recklessnl, Thanks for the suggestion. This has actually already been requested under #462. Please thumbs-up the top comment there to show support. Therefore I will close this.
Thinking about this, I'm not sure it's something I'd really like to have.
My main concern is that users may turn to such an option to set headings instead of using proper, structured, heading controls. In addition it will busy up the editor toolbar and further mis-align the WYSIWYG editor with the markdown editor.
The fact this hasn't been explicitly requested before may prove it's maybe not as "must-have" as you think, at least for most people.
Adding one extra icon to the editor is certainly not going to be an eyesore, if anybody would ever notice anyway. There are 24 little icons right now, you really think adding the 25th is going to turn anybody off? I really don't think that should be a reason to not implement a core feature of a text editor. I think I can speak for most regular, non-technical users when I say that text size would be a core feature of any text editor. It shouldn't just be developers who use Bookstack - the thing I love about it most is that spouses or family members are perfectly able to use it too to create a family wiki. It's straightforward and simple. And let's be honest - most people on Github are above-technical users and not really everyday technology users. So even if they don't request it, that doesn't mean it wouldn't help casual users.
And for those people who come from everyday text editor applications (like Word and Google Docs), text size is a standard core function for over a decade. I was certainly surprised to not find it in the WYSIWYG editor. I can only imagine how even more non-technical people could be put off by not being able to resize lines of text. It's been possible in Word since pretty much the beginning.
I don't really see the downside of it - you're adding one extra icon that's extremely standard in WYSIWYG text editors anyway and adding one small icon in a list of 20+ icons. It won't be noticed when it's there, but it's already noticed when it's missing. It would improve an already great application and make it even more family- / wife-friendly.
Agree with you @ssddanbrown. I've used some other wiki's and new users always ask or complain that this feature is a "must". Word has it because it's a word processing app. Utilizing the headers provided is effective and lets you stick to creating content, not worrying about how pretty it looks.
Agree with you @ssddanbrown. I've used some other wiki's and new users always ask or complain that this feature is a "must". Word has it because it's a word processing app. Utilizing the headers provided is effective and lets you stick to creating content, not worrying about how pretty it looks.
Adding this feature doesn't refrain you from using headers. You're arguing against adding a feature that many casual computer users have known and used for years. It won't interfere with anything you're doing.
On the other hand, not having this feature is a letdown for casual users who want to design their pages the classic way. Who are you to tell them they shouldn't do that? It should be up to the users. You want to use headers, fine. Other people want to use text size, why not let them?
Also I'd like to point out that you're only strengthening my case by saying:
I've used some other wiki's and new users always ask or complain that this feature is a "must".
There you go. Like you said, I'm definitely alone here in wanting this feature. Up to you guys how user-friendly and attractive you want to make Bookstack to everyday users, but to me it's very clear how the pro's outweigh the cons.
Other people want to use text size, why not let them?
I think the issue is the time to implement such a feature, as well as what Dan mentioned above about breaking heading controls. I understand that a use would want this, because they have it in ALL of their other programs for word/text editing, but just because it's there, doesn't mean it should be everywhere. Devil's advocate ;) @recklessnl
@griff3ng I find it a odd how you're adamantly trying to stop a feature from being added, one that would please a great deal of users. The world is bigger than yourself, and Bookstack has a lot more users than just you.
but just because it's there, doesn't mean it should be everywhere
This isn't an argument at all. You're not making any point here, it's meaningless fodder.
Other than the 'it takes time' take, you really don't have a lot of strong reasons for stopping this to be added. The time one isn't up to us, I assume the devs are doing this as a passion project, I'm sure they'll find time someday. It's not like there's a rush, and the rest of the app is so well designed, I'm sure they're perfectly capable of adding this feature when they have time. As for breaking the heading function - Word and Google docs have both, are there any issues at all with those features in those programs?
I rest my case.
Oh I don't mean it like that @griff3ng , I'll wait for someone like @ssddanbrown to reply to my above points and see what he thinks. You're not relevant in this issue at all. Let's hope it will eventually be added, I'll wait patiently.
Okay, Let's all keep it pleasant. Here's an enjoyable cat GIF if anyone needs a reset.
I don't think @griff3ng is purposefully "trying to stop a feature from being added", Just providing their point of view.
There are 24 little icons right now, you really think adding the 25th is going to turn anybody off?
No, But there does have to be a line somewhere, Though I know there's other toolbar improvements that can be made as it is. This isn't the core thing preventing this, yet just a point on the list.
Who are you to tell them they shouldn't do that? It should be up to the users. You want to use headers, fine. Other people want to use text size, why not let them?
I think both @griff3ng and I totally can see why users would want to control text size; but there are drawbacks to adding this, even from an end-user point of view. There will be many environments where they will value consistency in document structure over flexibility in font size. In addition, If we decide to add/improve features based upon document structure, (Increase search weight for words in headers for example), users may not receive the benefits since we can't assume how a page will be generally put together.
Other than the 'it takes time' take, you really don't have a lot of strong reasons for stopping this to be added.
Upon the above, the markdown editor alignment is quite important to me. I really want to align those editors at some point and, although we could work around it, this would make that harder to achieve. The actually time to implement this, just for the WYSIWYG, probably wouldn't be that much really, but it'd still be something else to keep in mind and maintain in the future.
Perhaps there's a middle ground, Have a font-size button that effectively opens the style menu, I'm not sure though, just thinking aloud.
Ultimately the obvious option here is it "make it an option" but this has come at a time where I'm getting exhausted with providing options as BookStack gets more diluted by it's optional features. In my mind I'd like to perhaps open up important parts, like the editor, for developers to hook into for customization. Then people could build little bits like this for others to add themselves. I'm playing with the idea of changing the editor so will keep this approach in mind.
I'll leave this open to discussion, It's not something I want to outright dismiss. I know I'm somewhat blinded by my own use and vision of BookStack.
At this point it seems that it's not about functionality, nor time or difficulty of adding this, but boils down to just your personal preference/vision. The point of the WYSIWYG editor in my eyes is to get text editing done fast and efficiently. Text size is just another standard tool in the toolkit that pretty much everybody is familiar with. It's your baby though, so you have to decide, but I think I've made a pretty case for a majority of casual users who might try out BookStack in the future, and the fact that so many other users seem to request it from other wiki apps speaks volumes too. In my opinion you would be doing BookStack a disservice by not accomodating these casual users (family members, spouses, children, etc) who just want to quickly edit a document on a family or friend based wiki. When it's your vision vs the wants and needs of your (future) users, I guess that's something you ultimately will have to decide.
I hope I don't disappoint with my view, but it's an honest pleasant view from a business side of things.
I dropped an early install of WordPress to favour BookStack for the ease of organising content and being able to allow users to read my manuals online and I could also keep offline copies in a physical folder as pdfs.
My bookstacks is used as a document/business manual. A staff manual. A help manual. A manual just for my accountant. I say manual, but some are just single pages as bookstack doesnt give me the option to have isolated pages which can be 'linked' to other books.
I have to disable comments (which would assist in my mistakes in writing, or a way of staff to comment that they have read a page - I wanted to have a memo book that simulated an office memo folder) as comment notifications has still not been implemented.
When writing out the manual, I struggle with a VERY BADLY formatted source code box for me to add custom html. There is NO word count, which is not mandatory but was nice in WordPress - after all it was for writing documents. The existing paragraph sizes and headings are totally unsuitable for a professional pdf document and waste a lot of paper space.
There is no way to set the font size in the pages, so when converting to pdf, the pages are not pleasant nor do they look professional.
Then converting to pdf to result in 'unknown error occurred' freaks me out, as it was only thanks to my hosting company that i managed to get bookstack installed on my server in the first place.
Then I have a backup to restore issue. There is no way for me to backup my books as an all in one file or as individual books. That scares me, for my future as I want to write all my text for the future development of my business.
My basic point is, that whilst I love Bookstacks, I am having to, after another year of using it, look at whether I should go back to WordPress or look for another open source option before my writing gets more in-depth. I'm even considering going back to MS Word and syncing the documents with my Nextcloud simply as word>pdf conversion is almost perfect. It makes sense to me why previous bigger companies i have worked with, still keep paper printing manuals and maybe i was hoping for too much from bookstack to achieve an online+offline version of my documents.
Bookstack should have plenty of tools for writers, show estimated reading time, formatting text and embedding images etc etc as it is software for writing documentation.
A dream would be to have like an 'editor mode' where all these writing tools could be shown, with the current setup as a 'standard mode' so everyone is happy. Markdown is limited in formatting so besides technical writing there are few options for it. I cant imagine any finance department or HR department writing about systems and procedures and policies using markdown.
I know all this is hard work but my comments are in good faith for the open source world with the vision of a very small business.
Bookstack should have plenty of tools for writers, show estimated reading time, formatting text and embedding images etc etc as it is software for writing documentation.
I couldn't agree more. Text size is just one of the many tools. I'd be happy too if more were added, like @aljawaid argues for.
Thanks for the feedback @aljawaid and @recklessnl.
At this point it seems that it's not about functionality, nor time or difficulty of adding this, but boils down to just your personal preference/vision.
It is about functionality, as per my previous comments explaining my functional concerns, but functionality is admittedly influenced by my preference/vision.
When it's your vision vs the wants and needs of your (future) users, I guess that's something you ultimately will have to decide.
It may sound a little backward but I try to ignore "gaining new users" as a reason for implementing a new feature. I'm tending to prioritise project focus over popularity these days.
Bookstack should have plenty of tools for writers, show estimated reading time, formatting text and embedding images etc etc as it is software for writing documentation.
BookStack is software for managing documentation, writing is one of its features. A subtle but important difference.
@aljawaid If you genuinely find yourself fighting BookStack so much an alternative solution may indeed be better. All page content is stored as HTML in the DB if you did need to move to something else. I do genuinely want to improve the export options, but PDF is really hard to do and global export is a big thing that I don't want to half-ass.
Again, I'm not flat-out refusing this to be something you could enable at some point, perhaps via an add-in. Just providing my view from a wider, project perspective.
@ssddanbrown I don't have a horse in this race really, I've made my preference for MD clear in other threads. I suppose if I had to chime in, I'd throw my name in the indifferent pool for this feature, but leaning more towards the no thanks side of that pool. My use case requires formatting standardization, hence the MD preference, so allowing users to get fancy with table formats and other types of styling would not be ideal (again, for me).
As much as some of us may want certain features re-considered or prioritized (ehem; Git backend, ToastUI MD WYSIWYG editor 😉), at the end of the day this is your project and your vision.
I have yet to observe you outright dismiss a semi-valid request/suggestion without first effectively communicating that you've considered the input objectively and then providing your view point with great tact; so, much respect for that. 👍
For my first time commenting here, I'd like to start by showing my appreciation for the work done on BookStack. THANK YOU :)
I think the conversation revolving around new and seasoned users is a distracting one that ignores the merit-based considerations for and against the request. Not to tell anyone how to approach their job, much less how to actually do it, but here's what comes to mind in my own mind:
- How difficult is it to implement?
- Does it provide usefulness to a non-trivially-sized subset of the userbase?
- Does it break the application in any way, from functionality to feng shui?
- Is there more important work to focus on ahead of this feature request?
I like this application and certainly don't want to burden others with providing something they themselves aren't enthusiastic about. That risks not showing appreciation for what's been created, and I truly appreciate BookStack. That being said, from my outsiders' naive vantage point, this particular feature doesn't seem to be a far-out request, doesn't seem to tip the ecosystem towards chaos in any way, and provides some functionality that is truly useful. Font size is a basic feature in many mature editors. In my personal opinion it really is useful, and I hope it does get implemented.
Huge fan, user for about 2 years now on multiple instances.
I know this is an old issue, but I'd like to add one more to the request for adding font size to the WYSIWYG editor, but for a different reason than I've seen listed here - accessibility.
A large number of people suffer from vision loss, either due to a condition or just getting older, and something relatively simple like the ability to increase font size without resorting to editing source code or increasing browser zoom would be a pretty significant quality of life update, in my opinion.
As a sysadmin responsible for selecting software that is a good fit for my users, this is something that I have to consider. I would guess that most people on the software side probably trend younger and thus have good vision, but a significant percentage of USERS of the documentation software in an org may not be so lucky, and may struggle to use software that defaults to a relatively "small" font. Things are of course exacerbated by increasing monitor resolution.
I actually had a user who used Bookstack regularly, but stopped after a while. Turns out he received a new laptop with a higher resolution than his old one and it was difficult for him to easily see what he was typing, so he just stopped using it and went back to Google Docs. Case study of 1, but I'm sure there are many more similar cases, and they often don't complain, because they're embarrassed.
@rdbtn-no Happy to address accessibility concerns, but I don't see how in-editor text size control helps here. Such cases would be reader-dependant rather than defined in-content by the author. I'd have thought that a global site-wide user option would be better here, although I'd probably want some evidence that in-site controls help upon browser zoom levels. As someone with weak & sensitive eyes, I often find myself zooming into sites nowadays, but that's usually a fine solution. If you wanted to talk further about a site-wide user zoom option, feel free to open a new issue.
The fact that we have to change fontsizes through html header is one thing.
The fact that people say "ow, but you can just zoom in the entire page to enlarge letters" is another (Zooming is a workaround and NOT something that should be done constantly... not sure why anyone would want it to be a normal activity)
But even though above things should already be unacceptable (Not sure how people can claim that they dont have issues with using workarounds so everyone has to bear with it, thats Apple mentality), surely noone can argue that with stuff thats unfazed by HTML changes like codeblocks is just terrible to not have options for. No matter how much I can adjust the size of other stuff through HTML, the font of codeblocks just stasy as tiny as they have always been.
@GitTimeraider
The fact that people say "ow, but you can just zoom in the entire page to enlarge letters" is another (Zooming is a workaround and NOT something that should be done constantly... not sure why anyone would want it to be a normal activity)
My suggestion to zoom was in response to accessibility concerns raise above. I would not expect this to be done constantly, and I'd consider the subject of text size for accessibility to be a separate consideration/concern to text size controls in the editor.
Not sure how people can claim that they dont have issues with using workarounds so everyone has to bear with it,
Not sure where this was said. I remained open to hear about accessibility concerns, I would just need to understand the fundamental issues with deferment to browser zoom controls so we can understand exactly what's missing and where value can be added.
No matter how much I can adjust the size of other stuff through HTML, the font of codeblocks just stasy as tiny as they have always been.
Here's some CSS, that you can add via the "Custom HTML Head Content" customization setting that would adjust code block text sizes globally:
<style type="text/css">
.page-content pre, .page-content .CodeMirror {
font-size: 16px;
}
</style>
Not sure if it's related - but when creating a list and formatting the text on the same line as the numbered list using one of the dropdown size/format options, it doesn't include the list number in the resulting formatting; i.e. setting the text to small heading still keeps the automatic line numbers at paragraph size, which looks weird and unintentional.
Maybe an alternative to directly controlling the text size of every letter could be to have configurable display styles for each existing format type. This could then also include lists and other implicit formatting styles. This would indirectly retain a relation to existing markdown styles, but allow users to change the visual output to their liking and if necessary completely override that to something different.
