Some Folks™ don't agree that interface design is similar to graphic design. I like to think of interfaces as a class of graphic design, which is a class of visual design, which is mostly applied psychology and cognitive science, which is all design.
Graphic design has three components: text, images, and space. If the question has to do with those, it's a probably question of graphic design. For example, let's take what you're reading: a forum post... with some text, images, and space. Holy moly, it's graphic design! So maybe visuals move around sometimes, maybe you can click buttons and other widgets that take you places. But wherever those components are laid out -- text, images, space -- there's graphic design. It's everywhere, let alone in web and interface (which are close enough as to be almost the same thing, if you ask me).
Fun thought: what does graphic design have to do with writing? When you see something like this and instinctively don't wanna read it, it's a graphic design problem.
I realize I've sarcastically mentioned before that "you can totally know if you like a piece of writing before you've even read it," but you can tell a lot from the way the author treats the text formatting and the first sentence. Because if even the first impression is lazy, it'll only get worse. (Also re: summaries on fanfiction.net. Stories with descriptions that say, "I suck at writing summaries," are a time saver. At least the author is honest about not knowing what's the point of their story or how to write concisely.)
So there aren't images, but formatting a piece of text is still in the neighbourhood of graphic design. In this case, the formatting indicates a serious rambling problem, so skipping over it is an easy choice.
Classes Paragraphs should have one responsibility!
Fun thought 2: what does graphic design have to do with coding? When my friend writes a function like the following, and I feel as though I should approach it with the safety of a 5 foot pole, it's a graphic design problem.
async def determine(self):
"""Determines the winner or loser of a game. If there is a tie, it will reroll for them."""
self.player_rolls.sort(key=lambda roll: roll)
lowest = self.player_rolls
lowest_rollers = 
low_index = 0
while low_index < len(self.player_rolls) and self.player_rolls[low_index] == lowest:
low_index += 1
highest = self.player_rolls[len(self.player_rolls) - 1]
highest_rollers = 
high_index = len(self.player_rolls) - 1
while high_index >= 0 and self.player_rolls[high_index] == highest:
high_index -= 1
loser = lowest_rollers[random.randint(0, len(lowest_rollers) - 1)]
winner = highest_rollers[random.randint(0, len(highest_rollers) - 1)]
result = [loser, winner]
Stuff like this = is[kind.of, (hard - to_follow)][!], and it's not because brackets and equal signs are innately intimidating. Like the ten-ton brick of text, this example can be broken down into more digestible chunks, with a clearer visual hierarchy (eg. more functions), clearer labeling (eg. more variables), more white space, and if we want to nitpick, a more consistent rag.
Btw. I mean line lengths.
As far as my limited knowledge goes, long written lines (functions, classes, and comments in code; sentences and paragraphs in writing) are a pretty accurate indication of an organizational problem. Not that I deserve to rail on my friend, of course. :D I love showing people my first programming effort, which has earned comments such as "What the actual love":
sy1 > 350 && sy2 > 350 && sy3 > 350 || sy1 > 350 && sy2 > 350 && sy4 > 350 ||
sy1 > 350 && sy2 > 350 && sy5 > 350 || sy1 > 350 && sy2 > 350 && sy6 > 350 ||
sy1 > 350 && sy3 > 350 && sy4 > 350 || sy1 > 350 && sy3 > 350 && sy5 > 350 ||
sy1 > 350 && sy3 > 350 && sy6 > 350 || sy1 > 350 && sy4 > 350 && sy5 > 350 ||
sy1 > 350 && sy4 > 350 && sy6 > 350 || sy1 > 350 && sy5 > 350 && sy6 > 350 ||
This bit is like a sentence that goes, "And the dog was fluffy, and the dog was fast, and the dog was brown, and the dog liked to chase the tennis ball, and...", except worse, because you don't even get to know that it's a dog, or what the dog is doing (spoilers: it isn't a dog, and it isn't doing anything).
On another note, coding Blackjack was a lot like explaining the game to somebody who doesn't have any concept of a deck, or cards, or how to play. It's not the machine's (or another programmer's) fault if it doesn't understand me or want to read my crap, it's my fault. Absolutely like actual writing.