C #1 - Phil / Hist
PRIORITIZE
Ocam's Razor - Effectivize troubleshooting by considering, and addressing, the simplest of potential problems first
PRIORITIZE
Ocam's Razor - Effectivize troubleshooting by considering, and addressing, the simplest of potential problems first
Entia non sunt multiplicanda praeter necessitatem. Nonne recte dico?
Oh, I'm sorry. I forgot you're not fluent in (virtually) extinct, ancient languages, the one in question being Latin. But alas, I forgive you, mostly because... Well, neither do I - the exception being that short, but impactful phrase. So here's the translation:
"Entities must not be multiplied beyond necessity." Meaning? If given the choice between a simple and complicated explanation or solution, opt for simplicity. Author? The 14th century English Franciscan Friar William of Ockham.
Although few know him by name, many people - especially academics of various fields, still to this day - understand, and actively recite, the gist of what he said, calling it, among other things, 'Occam's Razor.'
Although Occam wasn't completely original in coming up with the principle commonly ascribed to him (he built upon, or - if you prefer - mooched on established ideas established before he was even born), that's not important.
What IS important is what he believed and disseminated in his teachings, which is highly applicable to UI/UX. As you might have noticed by now, this book isn't exactly short on advice pertaining to prototyping and graphic design. An area in which it has, however, been sorely lacking thus far, is that of programming. So let's remedy that problem in one fell swoop, shall we?
As anyone who's taken even a surface-level stab at programming - front-end or back-end notwithstanding - has surely noticed, making honest mistakes - and setting out to fix them - is far and away the best way to learn and improve. But how do you know where to focus your attention?
Although programming languages such as HTML and JavaScript often have little in common - rightfully so! - the overarching way to work out an unexpected kink is usually the same: Consider the simplest possible explanation for your problem first, NOT the other way around.
Example: You're tasked with designing a web app that showcases a selection of residential properties. You're using HTML, CSS, JavaScript, and React.js to accomplish this.
Because of time constraints, you make the fatal mistake of coding away at your own discretion without really checking for errors along the way. Before you know it, you're presiding over a landing page that, albeit mostly pretty and functional, is subject to some serious glitching. What now?
Well, Smartypants. Since you didn't check yourself before you wrecked yourself (yes, even UI/UX book authors listen to old-school hip-hop), you're going to have to make the most of a dire situation. But do not despair.
Although you might be tempted, at first instinct, that it's your React.js file that's tripping things up, it's much more likely that your HTML file is the source from which your problem springs. And sure enough, that's exacrly what happened here.
Because of something as ridiculously simple as a poorly constructed div, your React.js code got confused, misdirecting where to utilize code. The result? It took an irksome five MINUTES to remedy, as opposed to an infuriating five HOURS(!).
If you're managed to remain spared from the likes of the aforementioned scenario, it's possible you're just one lucky goose with near-astronomical luck. Far more likely, however, is that you either:
a.) Are brand new to the game of front end app development, or
b.) Have no interest in learning how to code (exclusively focusing on UI/UX design via prototyping and graphic design - that's fine too!)
b.) Have no interest in learning how to code (exclusively focusing on UI/UX design via prototyping and graphic design - that's fine too!)
If you do harbor programming aspirations of any kind, however, you're more than a little advised to take a lesson from Occam's timeless problem-solving approach.
And remember, at the end of the day, you aren't even doing it for some bowl-cut monk from the Middle ages.
You're doing it for you.