tumdarb

A blog dedicated to discussing UI design, CSS, custom SBC builds, linux distros and even video games

[tumdarb]

The pitfalls of using only icons to convey information in software design

Designing software is a complex thing. A great deal of real life testing and user feedback is needed to create the best solution to the problem you are trying to fix. Obvious requirements are to keep things simple, make it easy to understand just by looking at it, and build it to be headache-resistent for updates in the future. All these things are easier said than done, of course. Such is the challenge of a designer’s work.

[tumdarb]

Jamming an mSATA SSD into the main shell of my Raspberry Pi 400

I have successfully jammed an mSATA SSD into the main shell of my Raspberry Pi 400. It wasn’t as straightforward as I thought it would be - in fact, most real hardware tinkerers will probably vomit in their mouths once they see how I achieved this…

[tumdarb]

Improve website readability with just two CSS parameters

element {

margin: auto;

width: 75ch;

}

[tumdarb]

Chrome OS Could Become the Future Leader of Personal Computing

**FOSS Enthusiasts**: Warning! This article discusses the use of proprietary software and places it in a *positive* light. You have been warned. No angry emails please...

I strongly believe that Google has created one of the best operating systems designed with the everyday user1 in mind: Chrome OS. It is undeniably simple, reliable, easy to setup, and ships with several years of support before any form of EOL kicks in. Most new models have built-in support for the Google Play Store and Android applications, which is extremely helpful for application development and debugging.

Oh - Chrome OS devices also allow you to run Linux in a separate container alongside the main OS (on supported devices). You can't complain about that!

Let's take a quick look at some other positive features worth mentioning:

Verified boot

Sandboxed environment (similar to how Chrome tabs work)

Automatic updates2

Incredible battery life (were talking 10+ hours with heavy usage)

My Personal Experience

A handful of months ago I snagged the Lenovo Chromebook Duet when it was on sale for my wife. Since she mostly does all her work directly through an Android phone, I thought of this as a nice companion device. And indeed it was/still is.

In that time, I played around with the tablet myself to have a better grasp of the ecosystem and it's obvious limitations. But a funny thing happened. I found that those "limitations" slowly started to disappear the longer I worked with the device.

So I decided to get my own Chrome OS device and snagged the Lenovo 10e Chromebook Tablet (on sale as well, of course).

Introducing the Lenovo 10e Chromebook tablet. This bad boy can do pretty much everything your current computer can do - but it'll only cost you $129...

10.1" display (1920 x 1200) / 400 nits

4GB of RAM

32GB of eMMC storage

Processor: MediaTek MT8183 Processor (2.00 GHz, 4 Cores, 1 MB Cache)

Now, I know that your initial reaction is most likely: "Wow, those are pretty barebones specs" and you would be correct. But truly it's all you need for this ecosystem to work. As cringe-inducing as it may sound, everything you plan to do on these devices should happen in the cloud. (Let's take a moment to avoid vomiting in our collective mouths)

Instead of using just a few marketing buzz words, let me breakdown how I personally tailor Chrome OS to my needs as a designer / developer:

Daily Tasks

Programming

Design

Gaming

Daily Tasks

I feel like going into great detail explaining how to do basic, daily computing tasks is a little overkill here. Spreadsheets, word documents, Zoom meetings, streaming media, etc. all work as expected. You have the ability to use Google's own web apps for these things or reach for other vendors such as Microsoft and Libre Office. Not being "locked in" to Google only software is nice and I appreciate the Chrome OS team being so flexible.

Programming

This one is a mixed bag and your own mileage may vary depending on your specific requirements. Personally, I use Github for almost all my main development work, so I utilize Codespaces. For those unfamiliar with the service, you are essentially running your Github repo in VSCode through the browser. It's pretty impressive stuff.

If you happen to be a user who uses GitLab or BitBucket to store your project files, Gitpod is a similar product to Codespaces (which I've also used on occasion). This too works exceptionally well.

Some may not like this programming setup but for me it works great. If running code remotely isn't your jam, you could always take a look at running VSCodium locally via Linux.

Design

There is quite a bit of flexibility yet again in this category. Personally, I tend to use Figma almost exclusively as my main design tool. The best thing about Figma? It runs directly in the browser. A perfect fit for Chromebooks3.

I do still open up Gimp periodically for photo-specific work. It runs in it's own Linux container and it chugs along smoothly, even with only 4GB of available memory. If all else fails, one could simply use something like Photopea to keep everything working through the browser (if Linux isn't your cup of tea).

Those of you in love with MacOS specific apps like Sketch - I can't help you here. You're pretty much stuck with Apple's ecosystem.

Gaming

There are other options (that we will get into) but the main gaming champion here is Stadia. No contest4. So long as your internet speeds are over 10mbps, of course. I use garbage satellite internet (counting down the days for Starlink to become available here...) with an average speed of 18-20mbps and Stadia runs like a dream. Even wirelessly. Now pair this with the portability of a Chromebook device and you've got yourself a beefier Nintendo Switch (kind of).

You also have solid secondary options like GeForce Now and Microsoft's xCloud (beta) for an even larger catalogue of games. Not to mention the ability to play a lot of Android games natively on Chromebooks that support Play Store applications.

Eye Rolling & Scoffing

I can already hear the screeching across the interwebs: "Wait - this is Google! They are literally Satan in disguise! No one can possibly use products from that evil mega corporation". And while I agree with the sentiment, I think going down this pure, 100% elitist approach to software just doesn't work with the everyday casual user. Not to mention the large swath of developers/designers screaming "Google is bad!" while working off an Apple device...

Hell even I, a fairly vocal advocate for open source software and privacy, can see the great benefits to using Chrome OS as a daily driver.

Testing out Chrome OS with your non-technical friends and family could help reduce a lot of headaches found in more "popular" systems. That doesn't mean advanced users have to switch over - use what works the best for you. For my immediate family members and social circles, I have nothing but positive things to say about Chrome OS.

I have no crystal ball to see what the future of Chrome OS holds - but it looks pretty promising to me.

Footnotes

"Users" referring to those mainly using their devices for word documents, spread sheets, media consumption, programming, messaging, minor interactivity (no heavy video or production editing, etc) ↩︎

These updates go mostly unnoticed as well - compared to that of MacOS or Windows... ↩︎

Your mileage may vary depending on how much RAM you have on your device ↩︎

Although, Stadia's current game selection leaves a lot to be desired ↩︎

[tumdarb]

Icons Should be Complementary - Text is Always Better

Designing1 software is a complex thing. A great deal of real life testing and user feedback is needed to create the best solution to the problem you are trying to fix. Obvious requirements are to keep things simple, make it easy to understand just by looking at it, and build it to be headache-resistent for updates in the future. All these things are easier said than done, of course. Such is the challenge of a designer's work.

But with this term of "simplicity", modern designers tend to take this approach too literally. In my 12+ years involved in UI/UX software design, I have lost count how many initial iterations of interfaces suffer from the same "dumbing down" decision making:

Using only icons to represent an action or function.

If you decide to stop reading the rest of this article, at least take away this one important thing:

Always try to use only text to convey your designs

Only after achieving this should you start reiterating those designs to include iconography. Even then, some UI instances won't even require you to do that. Most designers will actually find this process quite difficult, which is why it is so important to get right.

Icons make an ass out of u and me

Icons make general assumptions about what the user may or may not understand. Leading with this in your designs will end very poorly for you. Trust me - I've learned this through failed designs many times over. A certain visualization might be common knowledge to you, while differing greatly to someone else with an entirely different set of experiences.

I've found the only thing you should ever assume is that the user knows absolutely nothing. Please note - I'm not referring to their intelligence but instead their software literacy.

Just take a look at our now "famous" save icon so widely used in almost every piece of software - the floppy disk. Do any software users below the legal drinking age even understand the initial reasoning for using this icon? In all honesty, it was a terrible icon decision even when first introduced. No "hard copy" of the save action is taking place, most software creates this save in a digital space2. Yet, it was widely adopted and people just went with it.

Quality is not measured by mass appeal.

The argument could be made "Well, people learned to associate "Save" with a Floppy Disk icon..." and my response would be "But what alternatives were they given?"

Original software designers (and developers, of course) held all the power in early UI decision making. General users didn't know any better. Things were still new and fresh. So now our response is simply to shrug our collective shoulders and say, "Oh well! That's just how the save icon has to be now."

Hogwash. Make it a button that simply says Save File. I'm not kidding. Oh, it doesn't work well with your current design? Seems like your initial design wasn't very future-proof, then was it? I sound snarky here but seriously, so many designers put up imaginary walls around their design systems, making them incredibly rigid and difficult to adapt.

Take the time to do even a small thought / wireframe experiment: redo the layout and flow of your application without using a single piece of iconography. If you can't achieve this with even limited success, something is wrong with the overall design.

The hamburger menu is the 7th circle of Hell

In most use cases, the inclusion of a hamburger menu is indicative of an overly complex application. Too many cooks and all that jazz. Enterprise applications don't get a pass here either, as they tend to be the worst culprits of pouring out everything on to the user in some form of software vomit. Apparently sweeping all this interaction under the hamburger "rug" makes for a cleaner design. I assure you - it really doesn't.

New features are great, but stop dumping so much of it behind hidden, unintuitive sub-navigation. This design is such a "quick fix" and plagues far too many software apps3. Both desktop computers and mobile devices allow users to scroll - so let them.

I've discussed this in further detail here: Using Hamburger Menus? Try Sausage Links

But what of the "advanced" users?

I understand most applications will have advanced or "pro" users that have full knowledge of the product and wouldn't need things spoon fed to them. This is a more difficult problem that I myself haven't fully been able to solve without approaching each one on a case-by-case basis. Unfortunately, there is no "one size fits all" method to this. But, just because solving for advanced users proves difficult does not mean we should dismiss the merits of avoiding icons as a crutch.

Try for yourself

As I stated above, try doing a quick design experiment by replacing all your existing iconography in your application with simple text. I assure you that at the very least you'll discover some interesting design flaws in your system.

Footnotes

By "design" I'm referring to visuals - not programming or system engineering ↩︎

Some very early software programs did in fact save to an external floppy disk. My point still stands that many digital file storage applications still copied this iconography blindly. ↩︎

Not to mention how rampant it is on plain ol' regular websites. If you're hiding five menu items behind a hamburger menu for "mobile users" - you're doing it wrong. ↩︎

[tumdarb]

Hosting a Jekyll Site on Sourcehut

I recently decided to switch my personal, static site's hosting from Netlify to sourcehut pages. The process went fairly smoothly with only a couple minor hiccups; nothing rage-inducing. After everything was up and running smoothly, I figured writing out a step-by-step tutorial might help others who are thinking of doing a similar switch (or looking to host their first static site).

But first, let me briefly explain why I made the switch in the first place...

Why sourcehut pages?

Using Netlify as your static host is simple, intuitive and comes packed with a great deal of extra functionality you can easily add-on. So, why would I decide to switch over to sourcehut? The best answer comes directly off the main homepage of sourcehut.org:

Absolutely no tracking or advertising

All features work without JavaScript

Many features work without an account

The fastest & lightest software forge

100% free and open source software

After realizing all that, it's pretty difficult to stick with Netlify's proprietary stack...

Free but not "free"

I should note that using sourcehut pages does require you to be a contributing (read: paying) member on the platform. I'm a cheapo and selected the $2/month option but you might be inclined to donate more. Paying this "fee" is perfectly fine for me, considering the hosting quality (speed and storage) it affords me. It also doesn't hurt that I get the "feel good vibes" of supporting an important, open source product.

Keeping that in mind, let's get into setting up our static site!

Setting up your repo locally

Create a new account on sourcehut (or log in to an existing one)

Setup your billing to contribute monthly (tier amount is up to you)

Create a new repo under the git section1

Connect this repo locally (as you would via any other git host)

In this new local directory, place all your Jekyll files as you would with any other static hosting provider

The sourcehut build file

In order to have your Jekyll site build and push the correct files live, you will need to use sourcehut's build system. This will run every time you push out a new change to your repo (new blog post, page content changes, styling updates).

To make things easier, you can copy the build file below (remember to use your own information for usernames, git repo naming etc):

image: debian/stable oauth: pages.sr.ht/PAGES:RW packages: - ruby-full - ruby-dev environment: site: yourusername.srht.site sources: - https://git.sr.ht/~yourusername/your-repo-name tasks: - install-bundler: | sudo gem install bundler - build: | cd your-repo-name bundle install bundle exec jekyll build - package: | cd your-repo-name/_site tar -cvz . > ../../site.tar.gz - upload: | acurl -f https://pages.sr.ht/publish/$site [email protected]

Save this file as .build.yml and place it in the root directory of your Jekyll source code.

Then, you just need to push your changes to the repo. If everything was setup properly, you'll be able to see your live site at https://yourusername.srht.site (just give it a little bit of time to run the full build process)

Custom Domains

If you're like me and want to use your own custom domain - have no fear! This process is actually quite easy.

First, add a new A Record through your domain provider:

@ IN A 173.195.146.139

Then change the following environment parameter inside your existing .build.yml file:

environment: site: yourcustomdomain.com

And that's it - custom domain set! If you run into any issues check out the official documentation on custom domains.

Wrapping Up

Hopefully this helps to streamline the process for others to host their static sites through sourcehut. Having open and healthy competition among host providers and git workflows is essential to avoiding vendor lock-in.

Even low-effort support for open-source products (like where you host your static site or FOSS projects) can go a long way. Just some food for thought.

Footnotes

Thanks to McSinyx for pointing out that the repo used for creating your website can be named anything (instead of defaulting to your sourcehut username) ↩︎

[tumdarb]

Using Netlify for Dynamic URL Redirects

With the recent domain switch that took place on this website, I needed to have a dependable setup to forward my old domain URLs to the new one. While using something like "URL forwarding" through your domain provider could work, it doesn't natively support dynamic linking. Let me explain using a basic example:

A user clicks on a link that targets a post on your old domain: olddomain.com/random-post

You want that link to forward using the same permalink structure: newdomain.com/random-post

"URL forwarding" through your domain provider does not support this

Simple stuff. So, let's breakdown how to easily set this up on Netlify for free.

Setting Up Netlify

Create an account (or login to an existing one) and setup a new site1

Change your "old" domain name nameservers to match Netlify's (normally done through your domain register)

dns1.p03.nsone.net

dns2.p03.nsone.net

dns3.p03.nsone.net

dns4.p03.nsone.net

Back in Netlify: under Domain Settings you need to add your custom "old" domain under the Custom domains section under Domain management

Lastly, add the following content inside a _redirects file (no extension) to your website content/build (changing to your own domains, of course)

https://olddomain.com/* https://newdomain.com/:splat 301!

That's it! Now Netlify will dynamically forward all your pre-existing URLs from your old domain to the new one. No pesky .htaccess files or running your own basic web server(s)!

Hopefully this helps others trying to dynamically redirect their domains without the headache.

Footnotes

I normally set this up through Github / git hosting ↩︎

[tumdarb]

Using a New Domain and Switching Static Hosts

As you can most likely tell by looking at your browser's URL - I've swapped over to a new domain for my personal website: tdarb.org. I'm a fickle person and this is a random change - but it is one I've been planning to do for some time.

Let me give some minor background information and then get into the changes...

What about Ugly Duck?

I had originally used the uglyduck.ca domain for this personal blog as a loosely based reference to the "ugly duckling" story. This was based on the fact that I mainly focus on CSS and making the web more visually appealing - or beautiful, if you will - so the comparison to an ugly duckling becoming a swan made sense in my oddball mind.

But overtime I came to somewhat dislike1 it and set out to change it.

So what the heck is "tdarb"?

I explain this on my updated about page but I will mention it again here:

tdarb2 is simply my first name and last initial spelt backwards – Brad T. Mind blowing, right?

I've switched over to this naming convention to avoid having such a random "phrase" domain name while at the same time having a little more fun than just mylegalname.com. I also am a sucker for .org TLDs (although I don't know why).

I'm sure some readers will prefer it, some will be indifferent and others will hate it. Either way, it's my personal site and I'll do as I please!

Breaking My Website for a Day and Fixing Potential Link Rot

The transition I made yesterday from uglyduck.ca to tdarb.org was rough. I thought that I could simply launch the identical content on the new domain, test everything, and then simply set a URL redirect from the old domain through Namecheap3. Oh boy, was I wrong!

The bulk of my evening was spent figuring out why the redirect wouldn't propagate across all networks and why multiple forwards were occurring. In the end, I just tossed uglyduck.ca back up on Netlify and set global redirect rules in their handy-dandy _redirects file. (I will write-up a small post about this soon to help others). After a few minutes everything was working perfectly fine and best of all - no broken links or potential link rot! All thanks to the :splat parameter in the redirects.

As for my RSS feed, everything should forward correctly? I state that as a question since I can't confirm this 100% and RSS feeds are not my expertise. If I broke this for any of you, I apologize. I will pray to the internet gods for your forgiveness...

From Github to Sourcehut

That's right, I've switched this static site's hosting over to sourcehut pages and couldn't be happier. My reasons for switching:

I'm happy to pay and support the ongoing work at sourcehut (open source alternatives to Netlify, Github, etc. is important)

I've been wanting to become more comfortable with the sourcehut ecosystem - there might be projects in the future I would like to help with on that platform and it helps if you know how to use it :P

Sourcehut pages are fast - I mean really fast

It was slightly confusing for my ape brain to figure out the setup, but I got there eventually. I plan to do a detailed step-by-step tutorial to help those like me who may find it a little daunting. It's well worth the minor effort.

The Lifespan of uglyduck.ca

I still have ownership of the old domain for almost another full year. I feel like that gives users enough time to adjust and become accustomed to the new one. My plan is to let the domain die entirely when it goes up for renewal but who knows - I might very well keep it going if the mood strikes me.

That's All Folks!

I don't have much else to report besides having made minor tweaks to this website design (yet again) and I have also finally added a picture of workstation on the "Things I Use" page. That's it.

Footnotes

not hate - just discontent ↩︎

pronounced tee-darb ↩︎

Namecheap support were very helpful - this was more of a limitation of what their redirects can do ↩︎