Tuesday, November 28, 2017

paper airplane as "send"

Can I just say, I love the "paper airplane" arrow chevron that means send in a few mobile apps? It's so cute, and still works even if you don't recognize it, since it still carries a sense of motion / go / send.

Saturday, November 18, 2017

a hack to avoid iOS music app's odd decision to play the first thing that comes to mind...

I try to be forgiving of UI/UX decisions that seem foolish to me, understanding that sometimes there are design constraints I might not be aware of that are driving the show.

One longstanding iOS annoyance/oddity is this: when a podcast or audiobook ends, control tends to revert back to the music app, which makes sense, but then the music app starts playing songs from its library, starting at the top, alphabetically.

I suppose that's better than playing from all songs on shuffle, since at least I got to recognize that the Jackson's Five "A.B.C." meant it was time to switch gears, but for me it's worse than say, picking up where I left off, playlist-wise. Or better yet - why play anything? Is silence so awful? Would people assume the chain from device to speaker has somehow busted if there's nothing but quiet?

So, a small hack - moviesoundclips.net has a page of clips from Aliens, I took "That's it, man. Game over, man, game over!", padded it to be that plus four minutes of silence, called it "a a a - game over man" and then made an mp3 of the result. A little playlist hackery to make sure it had a spot on my phone and I was set - now when podcasts ends I should hear that, rather than the Jackson 5 (don't get be wrong, it's a great song, but kind of loud...)

Tuesday, November 14, 2017

wrapping text on a curve path in processing

I made a Processing app to help generate this tuba bell cover for my band BABAM!:

Slightly hackier than usual (I was watching football and hanging out with my Aunt), I used Processing vs p5.js (like I did for my Halloween skull bell cover) because of some fumbling getting p5 to load the font I needed. (Gill Sans Ultra Bold)

Source and supporting files here.

My code started from this Processing forums post but improves it by having the top go around clockwise and the bottom counter clockwise, rather than just do a full 360 around a circle and making people strain their neck to read it. Then there was a lot of fiddling by hand to get the circle sizes to look right and the words to be in the right place.

A better version would take the actual letter width into account - this one is implicitly acting as if it were a monospace font, but I just wanted to get through it.

UPDATE: I improved the program a bit (including a trick to let me use the mouse to fine tune some of the positioning) for the New Magnolia Jazz Band:
Source and Supporting PDE files here.

UPDATE TO THE UPDATE: I further fixed the file to let me make a transparent background for it, so I could more easily do the coloring. (The trick is to use Processing's PGraphics to make an offscreen version. And when you do that remember your dang .beginDraw() and .endDraw();, along with moving all the actual drawing functions to be references to the offscreen graphic.)

PROTIP FOR THE UPDATE TO THE UPDATE: I admit this is kind of obvious to everyone whose head isn't stuck in old school pixels like mine can be, but if you use layers properly, color the layer behind the art rather than try to floodfill in the layer itself..

UPDATE TO THE UPDATE TO THE UPDATE: the code is getting increasingly messy, but I made a new version with a blank area in the middle so I can use a washable marker to promote the message of the group my band is supporting (we want it to be more about the activism than the band.)

PDE Source Code

Thursday, November 9, 2017

mockupulator: simple rectangle drag and drop in p5.js

So random p5.js thing / tool that has a small chance of being useful for someone else: I was wanting to do simple but parsnickety layout mockups, but Acorn (my default image maniuplator) was being weird and I don't have Sketch (or much Sketch mojo) so I multitasked during the UI talk to make https://kirkdev.alienbill.com/2017/mockupulator/ - it's based on memories of an old "magnetic poetry" java applet I saw, you can just drag and drop the texty bits in the middle to where you want them.

Since the ENTIRE app is just the source code of that page (plus p5.js and the images I slice and dice) it would be easy to apply it to your own sliced up mockup.

Future versions I might never get to would make it save/restore state of the blocks and maybe make up blocks based on text rather than pre-existing image slices.

To quote Douglas Adams:
I have a well-deserved reputation for being something of a gadget freak, and am rarely happier than when spending an entire day programming my computer to perform automatically a task that would otherwise take me a good ten seconds to do by hand.
Ok, more like 50 minutes to save 10 minutes, but still!

Monday, November 6, 2017

"ExtJS was a mistake. One we, as a society, may never recover from."

When I worked at Pearson's startup Alleyoop around 2010 or so, we had an incredibly bright intern named Slater, currently CTO of his own machine learning startup.

On FB he posted
ExtJS was a mistake. One we, as a society, may never recover from.

Our dialog proceeded as follows

Oh my goodness. I thought you would be hipper and getting into the game after ExtJS was recognized as a mistake!
It's funny, I talked with this one engineer I respect but never should have been making UI architectural decision - In 2008 he put us on "Wicket"... all this client-y looking code is in Java, and you have to carefully keep synchronized these divs in the template and their corresponding nested Java objects... blargh)
In 2015 I was talking to him about his shoehorning us into Wicket, and what he, as a primarily serverside guy, would like in a UI. It turns out mostly he wanted to not have to learn HTML5 and especially CSS. "I want to be able to just ask for a button - programatically - and it gives me a button."
I realized ExtJS was probably an extension of this kind of thinking.
It was hard to learn and understand (rather opaque!) and also hard to debug in the browser - all these little widgets with absolute positioning and then given exact pixel coordinates... I'm sure they were doing some cool stuff early in a cross-browser way but man.
The hoops some engineers go through - the extravagant toolkist they then have to learn - to avoid learning some very basic stuff...

In a bizarre twist of fate, I recently picked up react + redux (not that I know what I'm doing on the frontend), and then saw an ExtJS stack. Suffice it to say I was horrified, but I think you're spot on about the logic.
I get not wanting to learn a new toolset (one could argue that a lot of cases where node gets extended beyond its sweet spots is another flavor of this same thinking), but anyone should be able to recognize when a framework is pushing them toward unmaintainable code.

A lot comes down to if developers prefer to understand things bottom up / via reductionism (in which case they value very transparent tools - even if they have to write a lot of the grunt work code themselves - the code base might get gnarly and complex but at least it's complexity specific to the application at hand) or top down / holism (in which case they might prefer a richer toolset that makes it easier to write in broad strokes - if the toolset is harmonious with the problem that's great, but chances are the toolset solves MANY people's problems, not just yours, so if you have to track down a mysterious 'whyd this go wrong?' it can be brutal)
Besides the holism/reductionism split, there's also nouns vs verbs; devs like me prefer verbs - I want to describe what I want done, in a more or less procedural way-- whereas noun thinkers want to make something that knows how to do the stuff. So here I like react, where the nouns (the JSX bits embedded in code) live sprinkled among the verbs of code, and you can put in a very relevant breakpoint, or inspect the state. Vs ExtJS, where you specify the nouns and it tries to write the verbs to get you there, and god help if you need to track down how the nouns got to the state they did.
When it comes to toolkits, my heart lies with vanilla-js or DOM manipulators like jQuery - I cut my teeth on caveman CGI, where the DOM was a very static thing that came back in one fell swoop from the server. When I added jQuery into the mix, the verbs I could do in the client multiplied, but the DOM was still that static noun thing, changing only at certain points which were more or less easy to track. Over the years I've felt validated that this is a pretty strong paradigm, as I've seen toolkits come and go, but React has come closest to feeling what might be the actual future, and I don't want to jeopardize my career by sounding like a cranky old stuck in the past dude.

Kirk, also I agree with this a lot. Personally I don't feel the noun/verb distinction super clearly, but that's probably because I switch between functional and OO paradigms a lot. I think especially for people coming from a noun-centric (read: Java) environment, learning the thought process behind a generally more verb-centric (read: javascript) environment can be very tough.
Additionally, I'm super, super reductionist. I like tools, and I love standing on the shoulders of giants, but I tread very cautiously when it comes to adopting a new framework, and it's very important to me to understand exactly where the limits of the tool are. I really enjoy APIs for this reason, and I think there are a lot of heavy frameworks that go the wrong way on this (for me at least) by enforcing large amounts of state, and making it unclear how you would extend the code.
I think jQuery is a really simple and straightforward way to built a project. I think that it's quick to pick up, fast to prototype with and for small projects there's nothing wrong with it. My gap comes from the perspective of maintainability. There are a lot of code smell niceties in something like python, generally focusing around clean code abstractions, decoupling data from logic, etc... that can be really hard to get right in plain jQuery. Even something like splitting code up into multiple files and using functions across them can get surprisingly gross pretty quickly just because of how the namespaces are set up.
I think that's the biggest advantage of React (I'll say Angular is pretty damn close to React, and from a macro-level they're almost interchangeable. Angular just feels like a bigger, clunkier version of React to me). Very clear separation of concerns. Clear lines of responsibility, and built for re-usability.

Enjoying this dialog Slater.
The way you used Java/Javascript as your example for noun v verb pinged something in me: I know the shared "Java" in the name is coincidental-ish but there's the "script" part - and that being verb-centric - "I want the computer to do this". It made me think of a defense of PHP I reread recently - Taking PHP Seriously - besides talking about how the odd dichotomy where the language is much reviled yet so many big league projects got at least their start in it - and in looking for some answers, mentioning that the script-ish way it gives you a "from-scratch" clean envioronment for each web invocation - that's actually tremendously powerful.
I can't always separate my long-standing biases (and roots doing personal projects where I was the only developer, though some of those codebases have lasted me decades, literally) from my "graybeard" experience, but I feel like I haven't seen much many systems that were clearly easier to understand and bring more people on later via leveraging higher level things. Whatever advantages were gained in using boilerplate were more than eaten away by a combination of new developers having less experience with the platform and generally being MUCH harder to debug from a bottom-up way. (i.e. completely opaque stack traces etc)
For namespaces... I dunno. Just throw everything into window.MyProjectName = {} and be done with it ;-D
The fact Angular and React feel so similar to you indicates that we view things very differently (admittedly I've done more hacking in Angular and only toy things in React so far). Elio who is posting here loves Angular, I hate it - who thought "client-JSP" would be a good idea? That is to say, "we love writing tags so much, we're going to let you make your whole View in nothing but tags - never mind how much syntax you have to learn in both the tagspace AND the plumbing that lets it all look like html tags. But more to the heart of our conversation, for me tags are nouns, the fairly static nouns of the DOM, so trying to make them all verb-y with loops and conditionals, and so it's blend of "this is a tag for the browser to render, this is a tag for the view's logic" feels strange to me. By putting the noun tags in the verb logic, React does something a little similar at a high level, but at least the logic and the display are in distinct languages (js vs jsx)
Heh, reminds me of How it feels to learn JavaScript in 2016 . Probably a warning sign that I still think more like a prototype cowboy is how much I looove just writing an index.html, a style.css, and app.js (and then I sort of love that "ok so put it all in one document anyway" paradigm ;-)

Anyway, very smart guy, one to watch out for.

Wednesday, November 1, 2017

iphone x is gestures all the way down

Slate: The iPhone X Takes Hand Gestures Too Far

I've never been a fan of gesture interfaces, and life with an iPhone X requires a whole new slew of them. (Conversely, I've always been a big fan of the home button; an easy to access "lets take it from the top" escape hatch can be enormously centering, like how when I click on a website's name in their header on any page I go to the site homepage.)

That's one of problems with the designer's dream of being such world-beater designers they they can stop having to actually, you know, design- having achieved the zen of "a piece of featureless glass"... the phone then just consists of an OS and apps - but having to designate certain finger moves as "ok, now you're communicating with the OS" makes a less known reliable channel, and one prone to accidental invocations, and takes away from the language of gestures that apps are allowed to use.