I don’t like infoboxes

EMWCon 2023

About me

• Hi, I’m River AKA Megan Cutrofello
• I specialize in writing software on top of MediaWiki, think complex Lua+Cargo data, with Python scripts to back it up
• Author of CustomLogs extension, have also contributed to Cargo and several others
• Previously:
• Worked for Fandom/Gamepedia & built Leaguepedia (https://lol.fandom.com)
• Currently:
• Blog at https://river.me
• Working for a B2B SaaS startup as a dev writer (unrelated to MediaWiki)
• Available for small MediaWiki consulting projects
• Contact: river.esports@gmail.com, available in Discord but email me first
• Also:
• Have worked for WikiWorks
• Sometimes active in Element chatrooms, if you ping me there I’ll see it

Anakin Skywalker

I don’t like infoboxes. They’re coarse and rough and irritating and they get everywhere.

Questions to address

1. What did Anakin really mean?
2. Did I write this talk just so I could make that slide?

Did I write this talk just so I could make that slide?

Yes

What did Anakin really mean?

Reasons why I don’t like infoboxes

• Relational logic problems (Cargo)
• Responsive web design problems
• Usability problems
• Information behavior problems

Relational logic problems

• Infoboxes only work for fields that are 1-1
• Team History: We’re almost out of space
• Social Media: No space for lots of fields. We could have:
• Name of platform
• Link there
• # of followers (updated via api)
• Date created
• Last post date made + link to it + maybe even text

But we can’t even consider this in the space provided!

(However the format is fine for fields that are 1:1, like “Name”)� (......or is it???? Name has: Name, transliteration, alphabet it’s transliterated from……)

Relational logic problems, cont.

• Here is how a 1:many display can look OUTSIDE of an infobox. There is actually space now!
• Not only is this a display problem, but also a coding problem
• How many tables are you updating when you update the infobox template?
• How much are you forced to sandbox at once?
• GUARANTEED people will have a worse schema because they couple display & schema
• Think, past_team_1, past_team_2, past_team_join_date_1, etc

Responsive layout problems v1

Version 1: You have just constrained your entire width of THE MOST IMPORTANT PART OF YOUR PAGE to 270px wide.

Responsive layout problems v2

• On mobile, your infobox is ABOVE the entire rest of your content
• How far do you really want users scrolling?
• On desktop, your infobox is to the RIGHT of the rest of your content (at least in vector)
• For how long do you really want a contracted page width?
• Infoboxes are not free space. Do not waste your pixels.

Usability problems

• Not everyone notices things around the peripherals of the screen in the first place. Your users might literally not even notice that infoboxes exist.
• In particular a Ctrl+F on the right side of the screen may be hard to notice even for power users.
• The point of headings is to serve as “entry points” to the text, so we can scan for the important information we’re looking for. When everything is an entry point, nothing is.

Information behavior problems

• People want to avoid information overload - they will ignore the infobox altogether if there’s too much information there
• Serendipity “highlights the phenomenon of encountering, stumbling upon or accidently discovering information instead of intentionally seeking for it.” This is more likely when related information is close together but infoboxes are all about putting unrelated information close together
• Infoboxes run counter to both of these
• For more on information behavior I recommend this book / book review - https://river.me/blog/book-review-looking-for-information/

All infoboxes are bad then?

Not exactly…

What is Anakin saying?

• Don’t let your infoboxes “get everywhere” - “have way too much ‘stuff’ in them”
• Regularly prune old fields that are unimportant
• Do you really need that photo?
• Is “Department Name” in the first sentence always?
• Has “Office number” been discontinued now that you’re remote?
• Maybe “Favorite ice cream” could be moved to main body text? Yes it’s cute but it’s not important

Great, delete these things!

• Concise infoboxes where every single field is legitimately important & doesn’t belong elsewhere are fine. Make sure you revisit them regularly to prune out-of-date info.
• And don’t put any secretly-1-to-many fields there.

What is Anakin saying (cont.)

• I also love this - in this case it’s not exactly an infobox, but the idea of splitting up your infobox content per section so you can get some serendipity back.

What Anakin is saying (fin)

• An infobox doesn’t mean an everything-box.
• Just because something is 1-1 with your entity doesn’t mean it belongs there.
• Programming solution to this: Set variables there & access them lower on this page. Yes, I know, variables, that’s out of scope of this talk.
• If something is 1-many it DEFINITELY does not.
• Don’t think about what you want to tell your readers. Think about: What do your readers what to know?
• Always complicate your own life to make your users happy.

Questions