simple way to do this...thats is all. It's basic functionality. I actually don't even want to make wiki's in confluence because of this. My company uses it but by god if something easier shows up I'll push so frickin' hard to switch. This is why everyone left HipChat for slack.
As I read through these comments, in particular my own, I would still say I think more direct User-control of font, size and colour would be helpful.
I guess there is an element of "if Word can do it, Confluence should do it too".
The use of Heading styles is helpful, but across many different groups with many different T.O.R./M.O. , a pre-defined set of 8 headings may be a little limiting and cumbersome mid-paragraph.
... but may be I am mellowing in my age and experience ?!?!?
As I look back over the last nine years of Confluence use by our 5000 world-wide industry association users in 500 different Spaces with a myriad of different terms of reference, "cultural styles" and indeed "modus operandi", I have to admit I have never been asked how do I use xyz font, or use size 6 or use this specific RGB colour ... ok, may be once??
I guess there is also a difference in Content Management Tools like "EzyPublish" for publishing a "magazine" style content with "fancy/glossy" look and feel with total control of everything on screen based on a few "back office editors" and thousands of readers s we need to make it look pretty or emphasised to obtain engagement and interest.
Confluence is top-class a Knowledge Management System with the premise of many-user collaboration to create, manage and share content .. many editors, many readers (and in our system many users with at best occasional use of the platform). I know in some sense that should not necessarily preclude being able to make content look pretty/emphasised.
I guess many of us have seen documents where someone has decided to use "13 different fonts", "10 sizes" from 4 to 36 and "17" different colours ... what a mess!
and basically un-readable. I have been known to be guilty as charged, but I am now trying to resist using all those options in Word.
So I understand a philosophy of protecting Users from themselves when the objective is to share information, which means it has to be reasonably consistent and reasonably readable with reasonable formatting.
Perhaps a compromise is allowing the User to control the 8 Heading style definitions within a page - still just 8 heading styles - just so there is not so much freestyle formatting of every second word, but still a general user other than a System Administrator can tailor the took and feel for their Space/page.
What was i thinking???
Give me 400 fonts, infinite size and 1 million colour palette!!
I don't think there is a need to compromise. I think there is an actual 'fix,' which would be to allow a space administrator to control what formatting is allowed in the space.
I believe Confluence uses TinyMCE as its text editor, and TinyMCE certainly has these features. Perhaps a space's administrator could be given the option to specify 'Strict formatting' and 'Loose formatting' for the space, the first to keep things as they are for those who want that and the latter to provide a more featureful experience closer to what some users expect. Having this settable on a space-by-space basis would allow a company to have 'strict' spaces and 'loose' spaces as appropriate. I think at this point it would be good for me to go in search of feature requests or make one myself. I doubt it'll get much traction, based on this thread, but it won't get any if I don't try!
As for anecdotes about how heavily requested this functionality is, every company is different but believe me I wouldn't be here if it wasn't a regular request! :)
EDIT: said feature request is here https://jira.atlassian.com/browse/CONFSERVER-5309 and i already commented on it in 2018 haha! I'm gettin' forgetful :)
I must say, "top-notch knowledge system" has never once entered my mind when thinking about Confluence. Terms like "archaic," "obscure," and "rudimentary" do.
Use case: I want to document some code. It would be nice to let it look like code - that is, fixed-width font - when discussing a variable. Markup does it. Even JIRA does it. Confluence, as a top-notch knowledge system, doesn't.
@James_Blasius Have you taken a look at the code macro in Confluence? It will format your code as a mono-spaced font. You can even have it do line numbers and syntax highlighting. See the below screenshot as an example.
This is what it looks like in edit mode.
And this is what it looks like when viewed.
calling Confluence 'top-notch' seems to reflect an ignorance of the industry. Compared to the open source and commercial tools used by technical communicators (tech writers) Confluence is primitive.
One suspects a chicken or the egg issue. Professional writers either would stay away or just give up -- especially in the face of claims that the software is 'top-notch'. I believe that if you asked experienced tech writers or members of the Society for Technical Communication for a review & audit you would get a ear full.
Confluence already offers a very limited set of fonts. Problem is, I use all the options available and still need a couple more. Bold, for instance, is already used for too many different (but good) purposes.
While it may seem a pain there is actually a real reason for this. My hunch is this won't change in the future. The main reason is that Confluence is meant originally to be a document repository. Typically you want all your documentation to adhere to the same standard for font/sizing so, they have not included it so that you don't have some goofball who is stuck in the 90s writing documentation in Comic Sans. There are workarounds such as cutting and pasting from Word, but ask yourself this question. Why do you want the different font sizes. Is it simply for emphasis? If it is then is font size really the best way to emphasize something? If you want font sizing for headings then you should use headers for that and not paragraphs.
You may be in a unique case where font sizing would be a good thing, but in my experience working with documentation if you allow users access to font faces/sizes you will get a hodgepodge of documentation styles that have no visual cohesion.
Here's a simple reason why some degree of font size control is vital
1/ Technical company with LOTS_OF_TABLES_WITH_ENTRIES_LIKE_THIS which get cropped when converted to PDF. I mean, sure, looks fine on screen - but for a document store, you should be able to export it for non confluence users.
With no control on the export and no control on the source document, you're left having great problems pushing Confluence to non-engineering.
if there was a competitor in this domain, I'm sure Atlassian would be adding features like this every few months
I agree to a large extent .. having specific font, size and colour selection would be really "handy" ... to some vital, or just an obvious feature requirement
But these wiki tool bars are often Open Source things (I have seen at least "99%" similar toolbar in other platforms) so the demand is often based on much broader usage than just the users of the Confluence platform ... so if that has failed to generate enough user demand Confluence is somewhat "hamstrung"
you said, "if there was a competitor" - well there are, but Confluence is right up in the top few and IMHO, do it better than most. Maybe therefore we have a higher expectation of it ... ???
As I mentioned below, you can "copy" special formatting into a page if you do the formatting in Word first and set the Web layout view and the "backward P" on
If fonts and formats etc are an issue, have you looked into a plugin to embed your Word template into the Confluence system? I am just about to start playing with using "Scroll Office" ....
So instead of getting a hodgepodge of fonts, you get a hodgepodge of super/sub script and arbitrary embedded HTML. That's worse, not better.
This philosophy of protecting users from themselves is a balancing act. When it involves a feature that most people reasonably expect from a text editor, and there is enough of a need that they're abusing super/sub or doing crazy stuff like enabling arbitrary embedded HTML, it is an indication that Atlassian is taking the 'protect users from themselves' philosophy too far in this case.
They could at least leave it up to the site administrators to determine what degree of formatting control to give their users. As it is, this lack of functionality is actively preventing users from using it in my organization. Sure, they can write things in Word first, but what about editing it afterwards? Should they just do their edits in Word and re-import? That's an awful workflow and hamstrings the collaborative functionality of the platform, which is part of what we're paying for.
Agree Sean Murphy. I think in this day and age, font options in the text editor should be expected regardless of the potential for problems. I spent 10 minutes thinking I was looking in the wrong place before I realized that the editor actually does completely ignore font.
Someone asks for a genuine, basic and highly important functionality, and one of the Community Leaders' response is "we just want to 'prevent goofballs stuck in the 90s from using Comic Sans'"???
I've barely seen a more arrogant response from a software vendor. Perhaps this responder is not an employee - but by leaving this page up for more than a year with Atlassian branding to be found by Google search, the stamp of approval is implicit.
I thank my lucky stars that one of the teams to which I recommended this expensive software called Confluence never bought it. I'm just imagining their faces when I tell them they can't change font size, and that Atlassian ("Community") thinks they are goofballs for wanting to.
I read back over the goofball comment again. "...don't have some goofball who is stuck in the 90s writing documentation in Comic Sans..." If an employee is writing documentation in comic sans and that's a problem then that employee's manager can tell them to stop. If an employee has a legit reason to want to format their text beyond what Confluence offers, what are they supposed to do? Learn HTML?
If Davin Studer is right about Atlassian's reasons, then I'm embarrassed that this product -- which I recommended -- has such a misguided philosophy. I did not buy Confluence so that it could dictate the company's documentation policies, which were in place long before Confluence came along. Evidently I bought the wrong product. Mea culpa.
@Aditya I do not work for Atlassian. My point was not meant to be arrogant and I apologize if it came off that way. I'm simply trying to point out the possible reasons for not having font face/size built in. You can work around it with a user macro if need be.
@Davin Studer I recognize(d) where you're coming from.
I think Rodney Hughes explanation (he just added it below a few minute ago)- is to me, kind and balanced, looking at both sides. He said it similar to what I would have said...in the large org where I work, we have thousands of users and hundreds of spaces, I can similarly count on one hand, over a period of time exceeding 10 years (!), where this request has come up. We are looking for the collaboration aspect primarily, not looking for font variability as a core (which can get problematic for some content creators). When we need it, we can get it through plugins, but it's probably on .01% of all of our pages.
Yes, it it would be nice to have the option but is that something to build into the core application when not many users are clamoring for it and it can cause distractions from those overusing them? And when the active marketplace provides options and user macros are available? They're open questions.
But let's keep the dialogue going. @Aditya i hope you accept Davin's apology.
@Aditya i hope you accept Davin's apology.
I genuinely do not wish to be apologised to personally over this :-) in fact, as I caused offence in my rant, please accept my own apology, Tom & Davin!
Dare I suggest a solution to this thread itself with another feature? :-D
Just like StackOverflow has the "answer" concept, perhaps there should be "mark as answer" button, so that helpful replies which actually answer the question (such as Milo Grika's down below) can rise to the top and be highlighted - and any further (useful!) meta discussion can still be upvoted and acknowledged such as this thread started by OP.
Regarding the matter of "importance of this feature" - this can get highly subjective, so the best I can do is state some opinions.
when not many users are clamoring for it
My belief (backed by no real numbers sadly) is that the "number of people annoyed by a bug or missing feature" is pretty high, but they are a superset of "number of people who actually bother to state their opinion and defend it with upvotes and arguments". So perhaps number of support requests isn't the right way to measure the need for this. It may not capture all the silent annoyed people - or worse - silent annoyed people who left for something else after a trial.
it can cause distractions from those overusing them
Software vendors should trust their enterprise users to be mature and/or have their own definition of 'correct'. Flexibility is what premiums are paid for. A Mac Pro is much more expensive than an iMac because of the modular flexibility it provides to satisfy business users' needs.
I personally needed this feature in order to highlight caption-text under screenshots I was posting in some documentation - I didn't want to detract the flow of reading. By making the text smaller & italic, centered middle under the images (what I think of as the 'standard way to caption') - the reader can quickly glance at the screenshot and continue reading the rest of the text unless they specifically want to read the image's caption.
when the active marketplace provides options and user macros are available
1. Plugins might cause performance degradation, and that's an unnecessary risk to take when this 'should' be a core feature, because,
2. If there was an "ISO Standard for text editors" - I'd imagine that changing font size through a set number of sizes would be a part of said standard, because the rest of software in the history of graphical computing has taught us all to expect it as a core capability - everything from MS Word to Disqus. Notable exceptions are social media textboxes like Facebook/Twitter - but that's not what Confluence is.
Seems to me that professional writing tools support Style Sheets. (I'd add style sheets to Adiya's "standard for editors")
Limiting writers to the options set up in style sheets takes care of the inconsistency and silly-choice-of-font problem. I rely on style sheets to remind me what had decided to use as the standard formatting for a document.
Have you tried the Span macro?
It's a little wonky in that in Edit mode, it appears on its own line, but in view mode it is embedded within the paragraph.
Just add the Span macro where you want the text a different size, enter the text in the body of the macro, then edit the macro and enter the size in the Styles field
Yes - the limited font management - size, style and colour - is a real pain!!!
But if you open Word
type some text in whatever font and colour and size
Set Word to Web layout view (CRITICAL)
Turn on the formatting button (backward P) (CRITICAL)
now copy the entire line including the backward P
when you paste into Confluence, all the html text formatting code (usually) comes with it :smile: (I say usually because I just tried it in this text box and it didn't work but I have tried it in our own Confluence instance)
Of course not handy when you are doing lots of individual text formatting .. but a rudimentary work around
Bring on a proper formatting wiki tool bar - I think there is a feature request floating around for a long time .....
I suspect part of the problem is that the wiki toolbar is open sourced code so it needs the open source community to do something about it
its a basic functionality that 100% of users expect with a text editor. I appreciate the workaround, but if I'm going to be opening other applications then I might as well just use them.
I suspect that there is no easy way to do this. So I'm moving on perhaps to a diff program and then just posting the link in the wiki.
As a "speed reader", I have to say that I fully support not letting people mess around with font size in the middle of a paragraph or sentence. Or even entire doc. As someone who has worked with partially sighted people, ditto. As someone with dyslexic friends that I write for, same again.
For me, changes of font, style and font size are incredibly irritating as they slow me down. One size and font, correct use of punctuation, good slepping, and a single style of emphasis are what I need. Please, do not change font, size, and certainly not background or colour, part way through what I am trying to read. Not without at least putting it in a separate section or panel.
By all means, change heading styles, styles for lists or pulled-out distinct sections, but please, please, please, write simple text in the body.
My dyslexic friends tell me "please don't use strikeout or italics, stick to bold or caps for emphasis". I try to.
There are, of course, times when it works. My rant above is about documentation and books - stuff where I need to read a lot of words. Short stuff, feel free (but that's not what Confluence is for). Longer stuff, you need to make it part of the narrative and that's not easy. I don't think many people have made it work, but one that springs to mind (a very slow read for me) was https://www.goodreads.com/book/show/24800.House_of_Leaves?from_search=true&qid=b1Ow6vOv3w&rank=1
In my case, we're writing documentation for technical systems which must be understood by non-technical users whose eyes will glaze over if they are presented with a wall of text. With respect, in all Atlassian's marketing material and documentation, I have never seen any mention that Confluence is 'for' documents over a certain length.
In our case things are formatted very deliberately to keep the reader focused on the concept that is being presented at that moment. We jump through all the hoops mentioned elsewhere in this thread to make that happen, if we have to, and as a result maintaining the documents becomes slightly more onerous (and it adds up!) These are our more technical users writing these documents. The less technical ones have either accepted the font limitation or stopped using Confluence -- perhaps irrationally, but there you go.
I understand the desire to limit formatting options but I don't think it's unreasonable to offer these text formatting tools as a per-space configuration.
Like I said above, this is sounding like a feature request now :)
<<...this is sounding like a feature request now ;) >>
That's certainly the way to go with this in my opinion, Sean, as I don't believe Atlassian monitors the Atlassian Community closely enough to distill all of the good ideas that might come forth.
I did a quick search and found a couple of feature requests related to this topic, which unfortunately have '0' and '1' votes respectively. Certainly there is more interest than that, so those interested need to get out the vote and maybe even 'politick' on this topic with Atlassians at Summit if they get a chance.
Perhaps you can find more if you look deeply (I just did a quick scan) to find these.
Just because there aren't many votes doesn't mean it won't be considered (from my understanding on how Atlassian makes these decisions on feature additions/improvements) but it certainly helps. One thing that may assist is to combine these (and any other) related requests into one.
To be on the record, I'm not personally opposed to having more font choices, especially if they can be managed on a space-by-space basis. I just see the practicality of Atlassian having to make numerous choices of where to spend their development time, and it appears there hasn't been an outcry for this one that has been loud or convincing enough. If you are correct about Atlassian using TinyMCE as the text editor, perhaps it's not a difficult thing to do.
> wall of text
Agreed - a wall of text is a bad thing to do as well.
The speed-reader in me wants good use of paragraphs, cut-outs, panels, embedded stuff that is clearly called out. The part of me that despises different font sizes (or even fonts) in a block of text hates it because it jars and break the flow. It's not a nice thing to do to us (or dyslexics, or the partially sighted).
>I have never seen any mention that Confluence is 'for' documents over a certain length
You're right, and I phrased my point badly there. Confluence is "for" collaborating on collections of things (mostly chunks of text) you want to share with other people. When I said "short stuff", I was thinking of the odd paragraph, or a page with a few sentences. The converse "longer stuff", I'm thinking more like essays or novels which are more like a "wall of text", where you should not be doing this sort of formatting at all. That formatting just makes it harder to read for many of us. When was the last time you read a book with loads of font and size changes scattered through it? In terms of physical length, Confluence is for the whole range of text lengths (and yes, I know someone who has written a novella in Confluence - 12 pages, one chapter per page)
>I understand the desire to limit formatting options but I don't think it's unreasonable to offer these text formatting tools as a per-space configuration.
Nor do I.
I'm not against it in itself, it can be useful. I'm against people using it too much, inappropriately or badly. I'm afraid a lot of people will, but it would be useful to places that are well-behaved.
I would need to be able to turn off the option in a space, but only if people were overdoing it and ignoring guidelines on when and how to do it. (That said, I can think of three places I've worked that would also want a global off-switch because they absolutely cannot use it, as it would make their sites unusable for their readers)
>Like I said above, this is sounding like a feature request now :)
>Just because there aren't many votes doesn't mean it won't be considered (from my understanding on how Atlassian makes these decisions on feature additions/improvements) but it certainly helps.
You're right, they'll take any good idea, regardless of votes. But the votes are one thing that feeds into whether they decide to stick it in a backlog.
Please see my other comments in this thread about 'styles' for fonts. (Style sheets in MS WORD). The 'problem' of too many crazy fonts was solved decades ago.
The acid test should be this: Submit the design and limitations of Confluence too a group of experienced technical writers, from a chapter of the Society for Technical Communication for instance, and ask them for a review / audit.
I think you would hear criticisms supporting those written up in this thread.
At first this was concerning to me too, but it's no more than an afterthought now. Our org (about 200 Confiuence spaces, 7500 employees, a number of all employee-spaces) uses a combination the built-in header fonts and superscript/subscript to alter the basic Paragraph font. Works well for us.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event