My F***ING Code Blog

Images + Maunderings = Code by @agentfin

[mfcb]

Turn into a giant spider #safetytipsforladies

@DanaDanger

  ...yes, I learned to make a gif. I feel like there's an easier way, or at least a way to make them SMALLER cause dang, this file is huge yo!

[mfcb]

Build your JET. See if it flies.

Alright. I'm tired of this.  Enough of this obfuscation [and having to explain to people that no, this isn't the same as in sports]. 

Do you really know what your MVP is? How do you know you've reached it?

What the hell does "viable" mean in the context of startups?!!? 

Maybe I've landed too hard on the Steve Blank side of all this. It makes sense to me that a startup is a product in search of a business model. Except, if you've gotten as far as that, seems we're preaching directly against this MVP idea. . . or at least the way it leads people to think.

Yes, I get that the pure version is "enough to be something for people to use." But folks don't think that way. Their eyes are on the prize: money. Besides, getting to a fully "usable" product is way way way too late.

JET: Just Enough to Test

You've got an inkling of a problem you're going to solve. Something you think is needed in the world that just ain't there. Well, go build it and see if anyone else agrees with you. 

Don't try to sell it. The point is to see if anyone even gets what you've built. Does it fit into their life, or is it something you're going to have to train them into using? Maybe they get it, they like it, but they want to use it completely differently than you expected. 

Now, I'm not knocking the beauty of selling simple things. If you are REALLY solving a problem, people will want what you make. You can figure the sell sheet any time. That's going to be a pricing problem,  just a matter of deciding between per use vs monthly subscription. 

If you're doing JET right, you've already got the features you need, cause you tested them, one at a time. They solved the problem. They fit.

[mfcb]

chat_with(taco).each do |scotch|

So here's my new theory. Call me crazy. Tell me how it's "not how you learned" and I'll go right ahead and tell you that's nice, but this is interesting. 

I've spent a good part of the last three years [yes, count them] banging my head against the wrought iron gate guarding the great wonder that is the enlightened land of RoR [ruby on rails to the as yet un-bruised]. Now, apparently some folks take to this stuff like fish to water. I've watched n00bs blithely build their first rails app and then sail along into code that frankly, I look at and think "my what pretty colors" ...and walk away. 

So yeah. I'm not a prodigy. 

But I'm also not stupid. 

That got me thinking a few times, as UXers tend to be trained to do, that maybe this was more of a VCR-clock kinda problem than a "I'm just not dedicated/cut out for/meant for this" type of thing. But I was never able to come up with an alternative. I did online courses, blazed along through Chris Pine and Hartl, realizing when I reached the end that I still had no effing clue how to actually solve a real problem when it got thrown at me. Frankly, I was still struggling with the syntax half the time. 

So I signed up for AppAcademy out in SF. Figured if I was ever going to learn anything, 40hrs a week for ten weeks might be enough for it to osmosis itself into my brain. Well. . . that was on its way to proving wrong [you can see some of the very excellent notes I took as the first few posts of this blog]. As it happened, the world came along and knocked me on my ass and sent me flying off to Chicago, so we'll never know if I'd have managed to weather the course and get an app built in the end. 

But now I'm in StarterLeague. 

Not taking the Ruby course. Literally taking everything BUT the Ruby course in fact. Might have run screaming from the idea of taking a Ruby course after all that. 

However...

I'm learning Ruby. 

Not from building things straight out. There are some awesome devs being hatched from the other class who are only too happy to hack away on the back end. Nope, I'm learning Ruby by writing HTML/CSS. 

Because now I have to. It's all smashed up in this damned Rails framework, bits of code just dangling all over the place, and I've gotta catch em all. Ya know what? It's great. It's freaking awesome. I'm not worrying about while loops or screwing up calling my controllers by their model names [I'm probably misspeaking there, but ha! not my problem]. 

Instead, I'm being immersed in this code. Getting used to wrangling with it. I'm also getting to see it IN ACTION. Yeah, sure. I'm "just styling" things, but those styles go around forms, and profile pages, and all sorts of other stuff. 

So this is my summation: stop trying to get folks to learn Ruby right out of the gate. Teach them some HTML/CSS. Teach them to build something they can see. That they can observe as they make it change. Get them cookin' with gas in the kitchen THEN show them the basement when they need to go get another steak outta the deep freeze. Don't just lock them down there right off the bat! First they'll hate you, then they'll leave. 

To all y'all who've been struggling to learn code the cool kid way. Stop it. The folks who are Rubyists now, and know their way around the language, either have been coding various crap for so long they don't remember how they learned it, or they're secretly missing limbs and kidneys from the trials and tribulations they put themselves through to get where they are. 

Take the easy route! 

Take the fun route! 

Learn some HTML/CSS [or even some HAML/Sass] and then go sling that code with the pros at a hackathon, or bribe someone to work with you over a beer[whiskey/coffee].

They might not have any idea how you do what you've gone and learned.

And you know what? You'll actually have fun AND have something to show for it [literally] at the end of the day.

THE REVOLUTION STARTS NOW!

THE FRONT DOOR IS OPEN!

Walk on in. 

[mfcb]

export SSL_CERT_FILE=/usr/local/opt/curl-ca-bundle/share/ca-bundle.crt

That was the answer. After somewhere near on toward 8hrs of hunting up and down through the internet [StackOverflow, Bundler's documentation site, Ruby-forum... all of the things] it was this one little line of code that somehow fixed everything.

Here's the thing. I'm not annoyed. I don't feel like I wasted my time. Sure, I might have been able to do something else, get to the answer quicker, with a bit of direct help. Certainly the rest of the SinkUP team would be happier as I'd have gotten more code written, as opposed to the current none.

But this really is part of it. It's like back when I used to play puzzle games on the computer. We didn't have the internet back then. So if you got stuck, you either straight up cheated and looked in the "answer book" if there was one. Or you bucked up and dealt with the pain of banging your head against the same damned wall for a while.

Now days, with the lure of the internet and its just-the-tip solution guides, I'm less likely to hold out and actually figure something out myself. Why waste time? But then, there's the kicker. I'm playing a puzzle game, the purpose of which is to befuddle me, and I'm CHEATING to get to the answer faster. Wasn't the whole point... yeah.

Now, with programming, it's not necessarily "the point" to sit and have to dredge through reams of trouble shooting. But here's the truth:

MOST OF WHAT YOU DEVELOP WILL BE BUILT FROM SNIPPETS AND SOURCES YOU DID NOT WRITE.

That's actually the GOOD way to write most of this. So, you want security check for your new app to be sure user data is safe. Should you write it yourself? Hell no! Go get one that's been written and proven and actually works! Same goes for making a heart in CSS, for creating a user login in RoR... oh wait. Did you say Ruby? Have you thought about what gems really are? What Rails really is? It's coding FOR you. 

So, what did I really learn? Well, I learned a hell of a lot of patience. If I was a kid taking the marshmallow test today I'd be getting 50 goddamned marshmallows for how long I delayed my gratification. That's not just some kinda tomfoolery either. Being able to deal with failure, and not just walk away but instead keep at it, that's what makes amazing musicians [oops, wrong chord], soccer players [missed that goal!], artists [wow, that does NOT look like your mom], marketers [uh, yeah, no, I don't need a new set of knives]... really anything. 

It's called GRIT. 

It's the one thing–not grades, not economic class, not IQ–that can actually predict success. 

Remember that book Freakanomics? Where you get to actually glimpse the savvyness of drug dealers and gang kingpins? Well, what do you think got them where they were? Sure wasn't a college degree or valedictorian of their high-school. 

So I'm happy with how I spent my Saturday... day... night. I upped my grit-factor. I learned a little bit better some of the trouble shooting that goes into every single day of coding.

Oh, and I got a reminder upside the face: if it's worth it, it's probably going to take a minute. 

[fix found on StackOverflow]

[mfcb]

Alright. It's time to throw down here. Mig Ryes style. 

We've gotten so far a lot of theory, a boatload of technique. Now, we put it all together. How do you get started on a project? So you need to build an app... What do you call it? What color should it be? What should it... 

Settle down there. There's a method to this creative madness. 

Step 1 - REQUIREMENTS: What is this thing supposed to do? Who's it for? WRITE THAT DOWN! If you know that you need for six year olds to be using this thing you're making, write that down. 

Step 2 - THEMES: Are there any obvious themes you can think of? Anything goes here. Just throw it down, get the juices flowing. Make those barely logical jumps you'd usually get funny looks for, and write those down. 

Step 3 - IMAGES: Take some of those crazy ideas and start looking for visual inspiration. Few designers pull their ideas just out of the ether. It's usually triggered by something they saw back whenever, or by active search [some call this creating a "mood board"].

Step 4: CHECK YO SELF: Ok. So maybe you got some good images there. You've got a few ideas that make sense. They're not too directly associated [like calling a flip cup game "Flippy"], but they're not too far out there. See if they have legs! Can you use more of the same language elsewhere in your project?

Step 5: START DRAWING: Ok, now you're rollin. From here on in it's using all those naffy grid techniques, maybe some Photoshop magic [we call them "chops"] and getting those ideas onto paper...er... screen.

So yeah. Basically, go until you reach the end, then stop. 

*Just to remind you all. This is freeing. Having a process, having some kind of constraints to work within, that's one less thing to think about. You work within the process and get creative on the inside. Just as developers have frameworks to work within, designers can create their own frameworks. Steps to take, rules to follow. 

[mfcb]

So as if being able to make things EXPLODE on our websites wasn't enough, well, we're also learning to build Transformers. Wait, no. Sorry. Do transforms. Sorry, anyway, let's roll.

The truth is, anything you can dream up doing to some poor image in Photoshop? Yeah, you can do that in CSS. The cool thing with this is that you can start building images from pure CSS and cutting back on your design time by going straight to the code. I'm sure there will still be times when I go back to Photoshop, and yes, vector images will remain king . . . for some things [personally I still love paper]. But yeah. This is kinda awesome. 

Not only can you stretch and deform images [or divs mainly]. You can also start constructing a 3D space on your page. By setting perspective [depth] you can determine some basic properties for your images to move in space. 

This is far from a perfect science. We're not really at CAD level here [though getting close]. There's some serious hacky-ness going on, unless you're in the mood to get deep into the math. But the point is also to remember, with these kind of effects, you can always just undo. 

The world of code is rarely permanent. So flip it, skew it, scaleY, translateX and yeah, roll out. 

[to the left to the left to the left to the left to the right to the right to the right to the tight now kick now kick now kick now kick... ]

[mfcb]

This might not look like much, but the class itself was mindblowing. Mig opened up the hatch and actually walked us through a lot of his processes, letting us see not just the end result, but the struggle that ensued along the way. 

Sometimes it really does take being given explicit permission to screw up, to make ugly, to have an actual template of failures to aspire to along the path to something good. 

For me, it was also a reminder that I don't have to just ditch my drawings when I go to the web. There's a place for the handmade within this process, a way to build it in, not as a crutch, but as a touch of something that makes design sense. 

If you've never heard of LayerTennis, then take a look in there. It's essentially a glimpse of how best to iterate, to throw down without concern or worry of what the final product might be, but an exploration. Each round SOMETHING is found to be brought forward. The rest? Scrapped [or landed for fodder]. 

Sound familiar? That's a crit. You rip everything you see apart. Find what works, toss the rest and go and build from there. Sometimes NOTHING will be working, but then at least you know a bit more of what NOT to do.

Every iteration gets you closer, but the important part is just to THROW DOWN.

[mfcb]

Don't go chasin waterfalls... 

One of the things that gets forgotten, especially when you're hanging out with just a bunch of UXers, is that you eventually do have to explain what you've been finding to the rest of the world. This is a process. This isn't just something where you toss it over the fence and just walk away. Your design thinking applies to your team as well as to the outside world. 

Have you considered ALL your assets? Have you identified your real unfair advantage? Because that should be directing you. 

This comes up as you head into building out products. There's only so much that can be built at a time, and knowing what's really key, is . . . well, key. You need to have a clear idea of your objectives, the solutions you're planning to implement and what the requirements are inherent to that solution. In other words, if you're using a door as the solution to an objective of security... you should probably make damned sure that it not only meets the requirements of open and close, but also lock.

So, you've got this down? Great. Because now we get into the magic of user stories. Basically, turning "we're going to need a lock" into "a user can lock the door" "a user can unlock a door" since having a thing is not the same as being able to use it!

This is another point where some UX needs to come to bear. Sure, it might be faster and easier to just make a door without a lock, but really, that's now just an impediment to the user! If it can't lock, why is it there in the first place? [think "user login"... do you need these? is everything being shared on the inside anyway?]. 

Finally, if your site is going to be content based [as opposed to just functionality] then you better be sure that it's easy for a user to add content. Even the most dedicated blogger will tire of writing if the platform they use is confusing, or doesn't encourage them to come back, post more, and maybe even interact with other content. 

Oh, and if anyone mentions "waterfall?" Run.

[see full size here]

[mfcb]

Exodus from the land of static websties happened a long time ago. The internet has slowly grown to mimic our world where yes, if you touch it, there will be some response. Behind the scenes, this has meant the evolution of jQuery. 

Since I've done a bit of Ruby, I'm also seeing another trend happening here. HTML/CSS? Yeah, welcome to the melting pot. The precise point where front-end and back-end hand off their jobs is muddy. It's not as clear cut as LinkedIn's job descriptions would have us believe. 

So, what can we really do here? Well, for one thing, you can make any website do the Harlem Shake. If that's not enough for you, then you're just going to be bored your whole life through. 

Some quick call outs: key:value pairs, so you can access say, names off a list; getters and setters, so you can quickly change everything or one type into something else [we turned all the instuctors at StarterLeague into breaded cats...]; you can add effects so images, words links [anything you can id] will explode or just run away when you click or mouseover them.

Yeah. So, pretty cool. Interactivity is what humans look for. I mean, we like it when the cat purrs when we pet it, when the dog fetches the ball when we through it. Humans demand a response to their actions. jQuery delivers it online.  

[curriculum by Shay Howe]

[mfcb]

I think finding a youtube video of an air horn may have gone to Shay Howe's head...

Yes, this sketchnote goes BEYOND ONE PAGE LONG. Very naughty. But, hey... It's HAML & Sass, and they're the bizz-natch.

A lot of this is remembering syntax, but other parts are also increasing efficiency in your code [as in CUTTING LINES]. Are you calling the SAME COLOR hundreds and hundreds of times? Lookin at you Tumblr, cause Facebook was, so don't be embarrassed to fess up. Well, why not make that a variable? 

This is kinda that place where Ruby and HTML and CSS all go out to a party, get drunk, and have a couple of babies. Yeah, that's where the twins come from, Haml & Sass, your new best friends. 

There's a lot more up there for you to look through, but the part that seriously blew my mind was being able to turn your widths and colors into variables... that you can then add to and subtract from!

Want that div wider for one of your media queries? BANG BANG BANG! Done.

Want that color darker for a hover state? KAPOW! You've got it 10% darker. Voila. 

This is gettin serious... 

And now, just for Arvin Dang, since he didn't know who Mitch Hedberg was when I said Shay was talking like him: 

[and a bit more if you want it]

[mfcb]

What's color? Welllllll..... If anything can blow your mind as to what color is and what it means, it's looking at how much cultural context changes the meaning of something as "simple" as green. 

http://www.informationisbeautiful.net/visualizations/colours-in-cultures/

Anyway, in the meantime, while that blows your mind, it is possible to get scientific about color. 

Hue: what we think of as "colors of the rainbow," the baseline of the color you're consturcting

Value: all colors are equal! ...but they differ in value. add some black to a hue and you get a shade. add some white? you've got a tint. yup, pink's a tint of red. you get it. 

Saturation: bright vs dull, not talkin about intelligence here. just how much of a hue you've got mixed in. eventually, it all fades to grey. dull dull dull, no mater how many shades of it you try to pawn off on a person.

Achieving harmony is also a [potentially] scientific process. Yes, you can get an eye for it too. But these things can be constructed. 

Complimentary? Yup, that's xmas.

Analagous? That's an "icy color palette" all the colors lined up in the blue zone. 

Split Complimentary? Now you're gettin crazy... 

[mfcb]

No, it's not SUPPOSED to be clear! If you're doing UX research and everything seems totally cut and dry, guess what? You're probably doing it wrong. 

Even something as "simple" as figuring out who your users are is a complex problem. The good thing? There's a path to follow to figure this shit out. 

Some of it is qualitative [demographics, some of the psychographic stuff], but a lot of it is quantitative. Why? Because when you ask someone to fill out a survey [and really, to get good quant numbers, that's usually what you're talking about in the end] they answer according to their own perception. They answer what they THINK you're asking, what they THINK you want to hear. 

Instead, starting with some qualitative research, some listening between the lines, then coming back around and testing you hypothesis? Yeah, that works. 

Quadrants: find your low hanging fruit

Profiles: the archetypical users you'll be addressing... yes, these sound like D&D characters.

Personas: taking your interviews and compiling them into some "real" people, as in Jane the Mom, and Ted the Mechanically-Challenged Chef

Mental Models: looking at what the thinking/feeling/doing is that a user is going through

Journies: a broad option that maps a product into a potential user's day, as in 'use case scenarios' and 'intercept moments'

Yes, this is REAL research. Just because it's not based on the answers of 5000 people, doesn't make it invalid... unless you've accidentally wound up with a whole slew of outliers. Eeeeek!

[see full size here]

[mfcb]

Ok. So back in the day when I first learned me some HTML/CSS chops, the biggest concern was if your tables and frames would translate over between Netscape and IE. Now? Well, you don't even know if someone's going to be looking at what you're building on a computer... or if instead they'll be trundling down a street, mobile phone in their hand [the most dangerous creature in the world is not a lion or a tiger...].

So, here's the thing. Responsive design? Only half of it is about the size and shape of what you're delivering. The other half is WHAT you put on the page. Do they need it? Does the content remain pertinent regardless of point of consumption?

Ok. Well, let's figure you got that handled. Media queries hop on in here. Not to be set as per "Here's the dimensions of your iPhone, then here's one for the tablet..." How many folks got caught with their pants down when the new iPad-Mini came out? How's a site supposed to handle the proliferation of device dimensions?

Well, these breaks you create with your media queries? It's about when your site starts looking bad... DESIGN your content. Don't let the portal design you.

Final word here: BIG shout out to Derek Eder, co-founder of Open City, co-creator of ChicagoLobbyists, and ClearStreets plow tracker [yeah, he's rad] for taking the time to give me the lo-down on what's going on under the hood with media queries!

EVEN IF YOU DO ALL THIS RESPONSIVE STUFF YOU'RE STILL JUST HIDING CONTENT. It's all still there, you're just letting each 'media' know what it should go and load in full. So think carefully about what you need. Avoid the extra code. 

[mfcb]

Welcome to TYPOGRAPHY: The Craft of Caring for Words.

Yes, you can get your point across on the screen or the page without ever delving into this world of type. But here's the thing. Look around. Really look at the words on a few pages. See the differences. Every letter? It has a personality. It has an agenda. 

It's like the old "don't shoot the messenger" deal. If your tone isn't getting across right, maybe it's not the words, but how they're formed and delivered. Somewhere between ascenders and terminators, amidst the kerning and the serifs [or lack there of] perhaps your voice has been lost, hijacked. 

So pay attention, not just to what you say, but how you say it. 

If you don't have anything to say, it's not design.

If you don't say it nicely, you will never know what you're really saying. 

[mfcb]

Week 2 of Carolyn Chandler's UX class at Starter League was chock full of info. She's the co-author of A Project Guide to UX Design and the Director of User Experience at Manifest Digital. Learning from the big guns here!  

We covered Heuristics, a set of criteria to systematically assess a website [or really any product, service ...anything]. From "Error Prevention" to "Control & Freedom" having a list of things to check for gets a UXer [and hopefully who/whatever is being assessed] past the gnarly world of feelings and into an unbiased space where improvements can be worked toward. 

Bridging over into some of the topics we're covering in the Visual Design course we touched on the 'Economy of Elements.' That would be the whole idea of not using 900 different fonts on your page, as well as maintaining recognizability throughout a site. Users get confused easily! If your buttons and color palette are different every time, how can the recognize you? Plus, guess what... fewer elements that you can reuse over and over makes expansion of a site, brand etc easier! 

Hierarchy should fall out from these common elements. What's important should be visually obvious, with assistance of layout, color, weight... all that good stuff. This gets tricky when you start looking at fluid and responsive design. Not everyone's consuming the web at their desktop anymore [and desktop screens vary hugely!]. We don't get into the whole "what do they want when they're mobile" here, but that's part of where hierarchy will help out. What slides away on a smaller screen, dependent on break points, should be decided based on what folks really want and need to see. 

Finally, we touched on research. Number one point? No one knows what they really want and need. You have to listen between the lines, dig deeper to find what the real problem is that folks are trying to solve when they say they need faster brewing coffee... maybe it's actually that their morning routine is really hectic since their bus doesn't arrive at a reliable time. So, what's the solution then? Instant coffee? Or maybe an app that alerts them when their bus is getting close. 

Oh, but you also need to be careful not to ask leading or entrapping questions: "Have you stopped beating your dog?" 

...um. I never started?

This is going to be fun.

[see full size image here]

[mfcb]

I'd asked the twitterverse earlier this week the difference between a Reset and Normalizer. I got back arguments for both, but as tends to be the case in 140char or less, the whole story wasn't told. 

I've decided it comes down to the difference between going to a Gallagher show and getting botox. In the one case, you're smashing the crap out of a pile of melons over and over. In the other case, sure, you can paralyze the crap out of an entire body by using ALL of neurotoxin at once, or you can just stop those eyebrows from wrinkling. 

Maybe that's a stretch, but think of it from the browser's point of view. It's doing it's darndest to render what you're asking of it. You don't need to give it a lobotomy first and then attempt to load in a whole new personality. It's got some idea of what's going, it just needs some instructions. 

So that was the first big revelation of the day. What followed was basically inspiration to create a new game to teach CSS positioning via a serious game of Battleship. I'm not sure I quite have the hang of how absolute and relative cascade together, but I sure as hell was able to see the differences when we mucked around with the code [fave HTML colors btw? DarkCyan, Moccasin and Olive]. 

Before and after I'll be intrigued to keep any eye out for. They seem like a nifty little fake for sneaking in info around the edges of what you're really concerned with. Captions come to mind, though I'm not sure that's really kosher.

.group and .ir will also be on my radar. Not IRL, but "image replacement" and seeing those kind of conventions pop up, having them called out, is a good portion of why having Shay as a teacher is so clutch. He's been in the industry, on the front lines. He's seen the lazy code and gone to the trouble of cleaning it up. 

So yeah. That was a damned dense lesson. Now I just have to go create the solar system for my homework. 

[mfcb]

There's something to be said for hierarchy. Anarchy and the free spread of ideas is all well and good in the physical world of interaction. But when you're confined to words and pictures on the 2D page of the web, some structure is necessary. 

Laying out the page is much like building a up an anatomy. You begin with a skeleton, something to hang all the squishy bits off. That's your grid. The 960 that's bandied about with such elan. Break a page down and what you get in the end is essentially plaid. But that's just the start. 

With structure you can dictate direction. You can elevate and denigrate information. That which is important can be brought to the top, either by placement, or by all those other lovely elements we're soon to learn, like color, typography and . . .  things as yet beyond my ken.

In the end though, just as we are, a website is a system. If you don't have some rules to follow from the start, it will fold and collapse under the pressure of information. Sure, those rules can be broken, once you know they're there. [breaking away from the anatomy side here... ew, guts] You can cut through a few trusses to install a skylight, but too many and the roof caves in [bigger skylight]. 

So know your system. Know its limits. Then get building, ok?