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.
Jonathan,
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.
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 (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.
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.
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
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.
It's 2018, still no font size in editor lol.
enable raw-HTML (note caution with doing so)
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.
Nah!! What was i thinking???Give me 400 fonts, infinite size and 1 million colour palette!!
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
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
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.
Good luck!
@Sean M
> 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 Definitely.
And @TomC >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.
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.
It looks like you're new here. Sign in or register to get started.
