The minimap is one of Xcode 11’s starring features. I know many people were excited for it at its debut but after months of exposure, I now just disable it in the Adjust Editor Options menu (the five horizontal lines of unequal width indicating the contents of the primary editor) and grab back that room on my screen:
I’ve spent some time recently considering exactly why it is I hate the minimap so much. It’s not just that it takes up valuable horizontal space (although to be honest, it’s mostly that). If it did a better job to help me navigate or conceptualize my code, I wouldn’t resent that space. Rather, I get little out of it and it’s a blurred colorful distracting mess for me.
In theory, the minimap is a specialized scrollbar for code. It highlights where are you with respect to the file. You hover the cursor over it to view tooltip details. Upon finding a section, you can quickly jump to it. Hold the command key down and all the tooltips appear at once for a quick and actionable overview. All contextual bookmarks are larger sized so technically “legible” although I can barely read them with my bad eyes.
I don’t care where I am physically inside my file, so the scope highlights don’t offer much. I care where I am conceptually. My jump bar gives me the same overview as the minimap (using the command key) without stealing screen space or distracting me with extra pointless blurry information.
What I am at a loss to figure out is how the minimap does that better than my beloved jump bar or why people prefer having the big jumble on-screen. As far as I can figure, the overview (whether jump bar or minimap command key) provides the most powerful tool because it relies on recognition of the details you’re looking for. But most of the minimap is designed around recall: where you are in the file, what the shape of your code is like, etc, which is a far weaker place for cognitive support.
So what am I missing? Why should I love the minimap? Please help me figure out what I am not understanding here and help me turn the minimap from an enemy to a friend.
12 Comments
Nope. Instead – THANK YOU!
You hit it perfectly.
Extra space (particularly on my 13 inch MBP) should **always** have a reason. Usually navigation?
I’m way too busy to learn how to shut the damn thing off – and now I know! Again THANK YOU!
PS: Apple still has their “good” side – AirPods Pro (hope I spelled it correctly) – but anymore they seem to have this “buggy” side too. How many versions of iOS were there in late September (sorry, I lost track and was dizzy). And we’re already at 11.2.1 GM because of….UITextView crashes? Ouch.
I enjoy how it shows the location of strings matching your current Find search.
Tells me something about how symbols are used in my program.
Try using MARKs, they are rendered in the map
Many people ignore a particular use of the minimap – understanding the complexity of some portion of the code, without having to look at each line. In most languages, complexity increases with the level of nesting of code. This is usually difficult to estimate when reading the code itself, since the brain is focused on what the code does, rather than how nested it is. By obscuring the text, and leaving only a bird’s-eye view of the layout, the minimap might help pinpoint parts of the code, needing improvement. It can be very helpful when working with someone else code, or with a code base, which you haven’t touched in a while.
I like it in conjunction with MARK so I can see where things like my protocol stubs are etc.
I would also like to be able to color vast blocks of code against Minimap to give me my own semantic color code referencing against code blocks – e.g. The purple code is about “Feature X” – then I could imagine Minimap becoming more useful on a personal level for my visual preferences.
Jamie hit one of the key points. By utilizing MARK, there are signifiers for sections of code without hitting ctrl-6. I also like to use it for reviewing code from others… some super nested code can usually point to some code smells or memory leaks.
Lastly, I don’t have it running when I’m on my laptop. I only have it going most the time when I’m on a desktop monitor. It’s fine on a 27″ monitor when real-estate isn’t a concern.
I don’t use it either, but I spoke with someone whose brain remembers code primarily by shape, and they said it’s a great way to quickly find and jump to things if your brain works that way.
It’s occasionally useful whe there is some physical structure in code that’s easy to see in the map that doesn’t have any other quick way to navigate to: a copyright or license statement, an especially large comment or ascii art, a long list of properties that you can’t rmember all the names of.
It’s actually most useful in plan text editors like Sublime Text for going through log files. Repeated error messages and error stacks usually stand out. I also used it to hone in on an esepecially large payload in a JSON .har file recently.
But yes, you’re crazy if not using the keyboard to jump to symbols by name most of the time.
I think you hit it right on the head. I have never found the minimap in any editor to be anything more than a distracting waste of space. I _always_ turn them off.
For me also the blue bar on left side is handy (displayed both in editor and in minnimap) showing source control changes. I see there in a larger scope, where are the changes I made.
I think it could be much improved by rendering extensions that implement a protocol in the way that MARKs are rendered. Then you wouldn’t have to write as many MARKs to get something really meaningful on your minimap. I’m not massively impressed with it otherwise either.
Minimap is only used interactively. Visually it solves no purpose. Hence, it would be wise to show the minimap only when you hover your mouse around the right edge of the editor. keep it hidden at all other times. This is the only right approach i can see.