• [A] Icon Logo Update

    01/26/2023 at 23:51 0 comments

    I noticed this fact maybe 2 weeks ago now: my designs have a lot of square diamonds but not a lot of squares. From the grills in #T^2 TyMist [gd0138] to the large squared diamond #Tetent TestCut [gd0139] makes when in use, it seems that I like square diamonds.

    Now, the icon logo used squares because I like(d) squares more than circles. Back over a year ago when I designed it, Teti was the only design with diamonds. Now, thinking about the hardware and software designs I have planned, it does seem like I'd be using diamonds more than squares. I probably might have realised this sooner since that was one of the reasons I liked the game Strata:

    My main worry was that it would look sharp... in a bad way. I really should've just gone into Fusion360 and made the change instead of thinking it over another 2 weeks.
    It looks brighter, like the diamonds are sparkles. Then I switched back to the current logo
    and my first thought was genuinely "Who is this plain and bland imita-- oh". Maybe it's just because the logo is over a year old and it's starting to feel a bit stale, but it just makes me think more towards "office" and... not as energy-emitting.

    I'll probably realign the diamonds before rolling it out (see aligned new logo below), but otherwise it looks fine. It also looks similar enough to the current one that it should still be recognisable and possibly interchangable. HP has 2 drastically different logos; I think I can get away with the same logo but one has rotated squares. I'm already imainging it opening up new potential motion graphic animation opportunities.

    [14th Feb 2023] Rolling out the new personal branding now.
    The curve of the brackets has been slightly tweaked, which means that the icon and full kelvinA look slightly more fluid and less orthagonal.
    I also decided to put a filleted chamfer in the E because I use those extensively in my designs and so shoud be part of my brand image somewhere.

  • [A] Logo update

    09/19/2022 at 20:03 1 comment

    Earlier today, I found out that The Verge just got a fresh new look (see below) and after seeing their new logo, I thought I should see if I could freshen up my own now that it's nearing to be a year old.

    Here is the old (top) and new (bottom):

    From using it for a few months, the only thing I thought needed improvement was visibility. The old logo became a hard-to-decipher blob a little to quickly for my liking.

    The main thing I did was increase the negative spacing from 0.25 to 0.375. A nice side effect was that this made the line in the A a perfect 1x1 square. This means that I could potentially animate from the 3-dots logo to the kelvinA logo and match up the dots.

    Next, I changed the line that comes from under the n so that it looks continuous. The base idea of this logo is that it can be made out of 2 lines. 1 line is the loop in the k and the other line creates everything else. The single-line idea was a feature of the verrry first kelvinA logo I made in 2015 all the way up to 2021.

    (2 lines diverge from the k)
    The logo is supposed to be a blocky fern leaf, but it looks like a Minecraft tree about to fall down from the weight or some kind of tatoo for some reason.

    The 2 above are made in Powerpoint, and the newer ones are made in Fusion 360. The hours lost trying to get the sketch solver to cooperate... (FreeCAD wasn't any better or worse.)

    Moving on, the next thing I did was reduce the width from 27.5 to 27. The idea was that I could animate 3 logos (each logo is 9x9) with a 0.25 gap, but I think the more predictable 3:1 aspect ratio is a more favourable solution. This change made the e look a bit compressed, so I added a fillet to the bottom of the square. It now looks more e and less E, as well as the filleted square looking a bit like a leaf (I like leaves).

    The biggest thing that's changed that I didn't even notice until right now (when I had to export the logo so that I could have a side-by-side image) is that the v has become noticably larger. I think this is a good accidental thing though because now the v looks similar in size to the n, the sharp edge of the v noticably cuts through the bottom line (I like sharp stuff such as Beyblade performance tips, gyro tips and the tip of a pair of compasses, and I don't like ultrarounded Googleization) and it accentuates the overall shape (of looking like a 2D spaceship sprite) better from a distance. (The biggest problem I had with the 6 years of the old-old logo style was that I could never just press "align centre" and the logo actually look like it was centred. While the n might look wider than the e in the 2021-present logo, mathematically it's the same.)

  • [T] Test Driven Development for DIY Projects

    06/19/2022 at 13:01 0 comments

    I started reading https://technologyconversations.com/2013/12/20/test-driven-development-tdd-example-walkthrough/ and got to the subheading "Requirement 2: For an empty string the method will return 0" yesterday.  I like their example, which is an "add" function. It shows the potential issue that even a simple sounding feature could have a bunch of smaller requirements that can be all too easy to conglomerate into larger but more descriptive requirements. Now, after sleeping on it, I've come to the conclusion that this might be a realistic way of getting progress done on projects like #SecSavr [gd0036].

    The Deliverable

    I plan projects based on the "deliverable" that Me In The Past requested. This is similar to starting at the end of a maze and drawing a line to the start. In this case, it is me mentally simulating what it would've been like in an alternate reality where I bought my project as a kit. I know that there is a high chance that the deliverable would still need refinement, just like buying a product and voicing suggestions for improvements, and so the main goal is to reduce the chance of having to start from square one because the deliverable that Me In The Past requested isn't what Future Me now requires. 

    Eventually, I'd converge on a project solution such that the only way I'd properly compute a new solution is if the deliverable of the current solution was insufficient (in other words, going back to the drawing board because the prototype failed). Even if the deliverable works, I know that the probability of a perfect design first try is very low.

    Relating to Test Driven Development

    Thinking about this, it just seems that I'm just doing 1 large (and therefore complex) test case instead of what was suggested in the article: creating 1 test case from 1 requirement (that fails since nothing has currently been designed), designing to fit that test case only, passing the test case and moving onto the next one.

    Now I need to think about the way to order the requirements to reduce the chance of a large refactor effort down the line yet still have the easier requirements closer to the top. Fusion 360 (and especially FreeCAD that is tackling the Topological Naming Problem for the future 1.0 release {I wasn't expecting them to ever get a 1.0 out for decades}) isn't very friendly when it comes to CAD refactoring (and is paritially the reason why I'm researching my options of writing my own CAD software in #enSweepen [gd0096]). In the present day, this and the desire to limit the filament consumption for 1-off prototypes due to cost and the environment means that my interest to reduce refactoring works against getting prototypes and tests out more frequently. 

    There's obviously a balance somewhere in there. Right now I'm likely too far on the "reduce refactoring" side of the spectrum to productively and consistently progress in my projects and will try to compute a new solution to this problem that incorporates ideas from Test Driven Development.