Conjurer of internet magic

Janie, my spunky little girl with a heart of gold, has been asking me to pray for "the little boys and girls in India". She wants me to pray that they would have "mommies and daddies that would love them and take care of them".  We've been talking about adoption a lot, and Janie's compassion has been revealing itself.  

The other day, I thought we needed to sponsor another child through World Vision.  I asked Janie to come and help me find a little girl from India that we could sponsor.  After we picked out Ismika, a little 4 year old girl, Janie wanted to know when she was going to arrive at our house.  I had to explain to Janie that we weren't adopting a girl yet, only sponsoring her.  Needless to say Janie was sad and then proceeded to beg me to bring home a little girl from India.  I have a lot to learn from my sweet little Janie.

There is always one problem that I run into with every personal project that I have ever worked on.  It's a cart before the horse kind of situation.  The scenario goes like this...

I can't entice users to use the finished product unless I have good data but, I can't have good data unless I have users.

and if I actually had a cart and a horse, it would visually look a lot like this...

So you might be wondering how I've solved this issue.  I have 2 lessons that I've learned thus far, which I thought I would share.

First, figure out where and how you are going to get the data before you put all the work into the project.  It can be pretty defeating realizing you have a product with no good way to entice users.

Secondly, don't build a product and then try to figure out how your going to get the data needed to get the users.

Hopefully you noticed that both those lessons are the same.  What I'm saying is that figuring out how to get the data you need requires ingenuity.  Sometimes building the product is the easy part. Figuring out the problem of having data without the userbase is the hard part and ultimately means the success or failure of the product.

I keep asking the same questions over and over again.  Why are there so many weather, mail, calendar and to-do apps?  Why do people keep coming out with the newer, "better" versions of these apps?  Why isn't anyone trying to build innovative apps? I believe I might have come up with two answers to these questions.  

The first answer relates specifically to mail, to-do and calendar apps.  People are looking for their app to do something that the app could never actually do.  People expect to actually get to-do items done if they just had a better, easier way to manage their lives.  They expect that they'll respond to more emails if they just had a better, cleaner interface.  Unfortunately, these apps don't get things done for you.

If you watch Twitter long enough you'll find that nobody is ever satisfied with the current product.  They jump ship for the next and more beautiful to-do app, only to find that they are (still) unable to check off their to-dos and respond to their emails.  The issue is that people expect those apps to do a job they can never do, and developers keep trying to build the next holy grail of apps.  Which leads me to my second answer.

Because of the ever elusive satisfaction of the customer, app developer/designers see this as a way to make some cold hard cash.  What they think is that they of all people have discovered the true interface for making mail easy.  It's like the California gold rush of 1848.  People have gold rush fever because it appears that there is money in creating something better than what is already out there.

The truth is, the odds are extremely high that you will fail when hundreds have already mined the same ideas for the gold.  The entreprenuerial app environment is risky any way you look at it, so you might as well increase your odds by thinking of something innovative that nobody else is doing.  We do not need another mail app.  We don't need another to-do app.  We most certainly don't need another weather app.

Finally! My post about my icon font workflow is ready for public consumption.  This particular post is meant to be a generic overview of how I go about creating icon fonts.  I in no way claim that this is the perfect way to do it, but after slogging through this myself it's the best way that I know how to do it at this point.

1. Illustrator - The first step in this long process is to create the icon in Illustrator. After creating the icon in Illustrator I then copy and paste the shape into Glyphs. For more information about how I do this, I pretty much follow the steps as outlined in this Github article.

2. Glyphs - Before I paste in my shape from Illustrator I set up the new font in Glyphs similar to the process mentioned in this Github article. The main concept is that you want to retain the shape from Illustrator when pasting and you also want to make sure the grid spacing is a relatively larger number. I played around with this number and settled on 19. I'm sure if I messed around with it more I could find the perfect number, but that's what I'm using at this point.

3. Export - After I've made sure that all of my nodes are on grid cross-sections in Glyphs I save and export the font using the settings in the aforementioned Github article. I'm not giving much detail right now because I don't really spend a whole lot of time on the font before this initial export.

4. FontFace - After exporting from Glyphs I open up the font-face kit generator and upload my .otf file. What I have done to make this process a little simpler is I've created my own local .html file that will reference the font generated. This is critical because of the need to test the fonts in an extremely controlled CSS environment.

The environment has to be controlled because any and all CSS can affect the visual output of the icon font.  Having this kind of control allows me to make sure that the font looks good and crisp in every browser.  Since I use this method for implementation of the icon font, my local file mimics these HTML/CSS settings.

5. Preview - Once I've generated my font I open up my local font testing file in Safari (preview on non-retina display only because you won't see the sub-pixel nuances) and see how it looks. Usually, it looks terrible and blurry. My first inclination was to turn on CSS font aliasing, but DO NOT do that. Font aliasing is only a fix for Chrome and Safari and your font will look horrible in other browsers.

Also, remember that whatever CSS you've applied to the preview is usually necessary to use when you implement the font for real. For example, if you are tweaking the font with a text-align center on it, you can get it to look right, but if you then use the font without text-align: center there's a potential of the font being blurry. If you find that a font is rendering blurry when you insert it into a real application the most likely cause is that some kind of CSS is messing it up.

6. Photoshop - After I've seen that my font looks like a big blurry mess I take a screenshot (do this on a non-retina display) and paste it into Photoshop. What I'm trying to do here is see where edges are crisp and where they are not. I usually zoom in as close as possible to get an idea of what looks bad. I also measure the dimensions of everything to make sure everything is correct.

7. Glyphs - From my inspection of the font in Photoshop I now bump the edges that are blurry a couple points in the opposite direction of the blur. In Glyphs this can oftentimes make the icon itself look a little strange, that's ok because we're only concerned with how it looks in the browser.

8. Rinse & Repeat - After tweaking in Glyphs, I now repeat steps 3-7 as many times as it takes for all the edges to look ultra crisp. I've gotten good enough at this process that it's pretty quick now.  I usually have to repeat steps 3-7 about 7 or 8 times, but it might take you a little while longer at first.

9. Browser Tweaking - Once Safari looks super good, I check the font in the other browsers. Chrome renders like Safari, so no worries there, but I have had issues with Firefox. Usually, one of the borders is a little off. If this is the case I will do step 3-7 again. What happens is that sub-pixels in the font don't always render the same in each browser. You can actually tweek the sub-pixels for the offending browsers, but still retain the crispness in the other other browsers.

Note: Windows - Using the technique above will get you pixel-perfect icons on OS X browsers, but won't on Windows.  Windows renders fonts a lot differently than OS X and eliminates one pixel off the dimensions of the icon. While that doesn't sound ideal, it actually looks really good and consistent. I've tried a bunch of other ways and methods, but they all result in big blurry messes for FF on OS X and all the browsers on Windows.

I just got excited in a super nerdy kind of way.  Select boxes are a pain in the rear to style and usually involve graphics and Javascript to make it look super good.  Well, I'm here to tell you that I just styled up a select box with zero graphics and zero Javascript.  This HTML/CSS combo works in IE8/9, Safari, Chrome, Firefox and Opera.

I've put the HTML and CSS on jsFiddle and you can see it here http://jsfiddle.net/teevio/uvvcx/.  There's really not a whole lot to the html and in this example I was using an icon font for the graphical element, which you can see in the image on the left but won't show up on jsFiddle.

The main concept is that the select wrapper handles all the graphical styling.  Since Firefox, Opera and IE don't let you change the "arrow" part of the select, the select box is made extra wide and the wrapper hides the overflow.  To get the entire select box clickable, the :after pseudo element is used and then positioned underneath the select box.