LinkedIn, Bullets, and Markup, Oh My!

I write a LOT. I've written countless game design documents, strategy documents, product requirements documents, treatments, proposals, wiki entries, Jira tickets, social media posts, cover letters, and resumes.

I often alternate between writing bullet lists and blocks of text. I do this for several reasons:

• Less words reduces the cognitive load for both reader and writer when the volume is smaller.

• Less text is better. It reduces the perceived cognitive load which can affect the motivation to actually read in the first place.

• Grammar rules are simpler. No need to connect sentences or build transitions.

• Points that don't have to flow from one point to the next.

• It's frequently faster to spit out ideas in a list form.

• It's easier to keep your place and reference back from a list of separate points than a paragraph if you're taking actions (such as implementing specifications).

By comparison, here's largely same content I just presented in a paragraph form:

It's generally better to use less words when writing because the volume of words on a screen takes energy to consume and blocks of text register are "more work" --or more cognitive load--which can make it both harder to read and less likely that it will be read. In addition, block form prose requires transitions and grammar to guide the voice through the thought processes which can be bypassed by just listing out main points.

Speaking of main points, sometimes you really have to stretch to get them to have that rhythm and flow which creates a good reading experience in the first place. This again brings us back to more words.

Finally, it's just plain faster to write a list. And it's unnecessary to go back and edit that list into a block of text because it won't do anything to help the reader consume it.

Bullets in Professional and Technical Copy

I consider bullets a must for technical writing (such as PRDs) where the goal is to get information across with precision and ease of consumption. If you read last week's #FeatureFriday, you probably noticed that most of it was presented in bullet format because it's a great way to get out those product requirements.

I've said it before and I'll say it again:

The "correct" format for delivering information is that which is easiest to write and consume.

Many platforms allow user-created content to be presented in bullets. Some platforms that support bullet lists:

• Slack

• Jira

• Figma (added this in May 2020)

• Google Docs

• ChatGPT will output content using bullet lists as well as bold and italics

Platforms/features that don't but should:

• Social posts - LinkedIn, Threads, Facebook (Xitter posts are too short)

• Reviews - Yelp, Amazon, Google

• Jobs, projects, education, and volunteer sections on LinkedIn

The reason LinkedIn stands out is because it is a business platform. People talk about work. They post things about jobs and job history (and most of us know that a resume is better in bullets than walls of text). It's straight up weird that LinkedIn doesn't give you the option to use bullets on the job history section.

So why can't I use bullets on LinkedIn? Why am I fiddling around with emojis just to

🔷Simulate with this

🔷Pale facsimile of bullets.

🔷Besides, these emojis have limited ability to be parsed as bullets because they don't carry the text alignment/indent to the next line of bullet

🔷Look at this. This isn't easy to read.

🔷It's cringe.

It's not complicated to get bullets along with bold and italics to work by allowing users to add just a wee bit of markup to their content.

What is a markup language?

Markup languages are how we store and describe information about how things should be rendered or structured. HTML is one of the best known markup language ("HyperText Markup Language"). They can be heavy, allowing for a lot of variation: LaTeX, for example, is a robust language that is often used for showing more complex equations. They can also be used to structure data as in the case of XML ("extensible Markup Language").

Lighter weight markup languages are generally even easier to read inline and include BBCode, Markdown, Wikitext.

Markup will allow users to add, and the content to store, indicators of where bullets as well as bold and italics are located in the text.

So, what does it look like?

I did double check that they don't work for posts even as I was surprised they worked in the article editor. Did you catch this post:

Sticking to only few simple bits of markup will also reduce the likelihood of having to add more escape sequences to the strings to store and transmit them. through the tech stack.

Implementation

Markup language, like most code, is written and stored in every day string characters. Because they're strings, there's very little changes in storage needs on the backend. The server will, as part of preparing the content for the browser, convert the markup into HTML for the browser to render on the client side.

The "requirements" for the conversion are straightforward:

• Text enclosed in one asterisk on each side should replace the first asterisk with <i> and the second with</i> HTML tags.

• Text enclosed in two asterisk on each side should replace the first asterisk with <b> and the second with</b> HTML tags.

• Lines of text that begin with an asterisk and end with a line break should replace the first instance of the asterisk with <ul><li>, the next line break with a </li>, the following instances of asterisks with <li> and breaks with </li>, with the final line break before a next line that does not begin with an asterisk to be replaced with </li></ul>

Easy, peasy, lemon squeezy. All we have to think about next is the editing experience for the user:

To WYSIWYG or Not to WYSIWYG

WYSIWYG stands for "What You See Is What You Get". Generally pronounced "wizzywig", its an interface where the editor can see how the formatted document will be displayed rather than seeing the text as markup.

As the markup and display needs become more complex and the user editors often need this kind of editor so they can be better accomplish their goals. Many CMS tools support WYSIWYG. In the early 2010s, MediaWiki added support for a WYSIWYG editor making it even easier for folks who don't know Wikitext to contribute content because less and less users were comfortable with markup.

HOWEVER, I submit that a WYSIWYG is not a necessity here.

For one, we only have small amounts of markup. You don't need—or want—to give users too much markup in the case of the places where I recommended bullets be "allowed" anyway. You wouldn't want them to have the ability to insert things like hyperlinks or infinitely nested bullets for example (one level is fine for social media; two-four for most writing). Nor do you need them playing with colors, or text sizes, or inserting their own headers messing with branding and accessibility. But bold, italics, bullets, (and numbered lists) are all friendly and would help make the content much more readable.

The other reason the MediaWiki case differs from our use case is that editors are not coming in to edit a large existing piece of content already full of scary markup. They are writing their own posts and have nothing to intimidate them from editing.

Conclusion

LinkedIn, you're a platform for networking revolving around my "work" profile which works quite similarly to a resume. Like a resume, you should support bullets not just in the job history section but in all areas where we can post about business and technical subjects.

An elaborate implementation where you redo all the input fields as WYSIWYG editors isn't required when it's only a small bit of markup. Just keep it light

Heather Arbiter is a Product Manager and social media junkie who has been receiving praise for her writing throughout her academic and professional career. In high school, she was accused of plagiarism due to the quality of her prose, an accusation she now carries like a badge of honor. She's known for her abilities to write concise user-facing copy, clear technical documentation, professional emails/cover letters, and persuasive social media posts. Heather has many years of experience writing in markup from HTML to LaTeX to Wikitext.

#FeatureFriday is a biweekly newsletter about the intersection of product, gamification, and behavior written with a personal touch. This is the 16th edition of the series and was published when the newsletter ran weekly.