This teetering arrangement of browser tabs would then fall apart when I clicked a link to a ticket in an email notification (opening yet another tab in the wrong browser window). Once I accidentally destroyed a live database table because I got my windows mixed up. Whoops.

With iron resolve and kung-fu like discipline you might be able to keep only one window or tab open at a time, closing out all others as soon as you’re focus shifts. Unfortunately I’m fresh out of iron resolve and my kung-fu is weak.

Fluid

Fluid is a app that lets you turn websites into an app for your mac. Fluid creates a web browser that loads only one page. For example, if you use Google Docs you could launch Fluid, give it the URL for docs, give it a name (like ‘Docs’), and optionally give it an icon.

Fluid will create “Docs.app” and save it in your Applications folder. You can double click the app icon and go right to Google Docs. The app works just like any Mac app. It shows up in Launchpad, Spotlight search, in your dock, and when you Command-tab to switch applications.

At work I have a fluid app set up for all of our work apps. This way I always know what window is what (they have icons!) and it’s fast and easy to launch or shut down one of these apps without messing with my browser. If I crash my web browser while dinking around with JavaScript, my web apps stay open.

The basic version of Fluid is free, but for $4.99 you can upgrade to get features like full screen mode (in Lion) and other neato features. It’s cheap. Support your indie software developer.

Browser Fairy

Having all my web apps in their own application is great, but if I got an email notification to a bug or wiki update, the links would still open in my default browser. Now I’ve got the bug tracker open in two places. Boo.

Browser Fairy is an app available in the Mac App store which sort of sits between links and any browser you have installed.

You set up Browser Fairy by making it your default browser. Then you tell Browser Fairy about all the browsers on your system. When you click on any URL anywhere, Browser Fairy intercepts it, and then re-routes it to a browser your choose.

For example, if your company’s timesheet tool only works in Firefox, you give Browser Fairy the base url (maybe http://timesheet.jobbity.job) and anytime you you click a link to the timesheet app, it will automatically open in Firefox, while all of your other links open in Safari.

Since Fluid apps are just single-serving web browsers, Browser Fairy treats them like Firefox, Chrome, or Safari. So I can configure wiki links to go to my wiki app, bug links to the bug tracker, code reviews to the code review app, etc. All other links go to Safari.

It takes a little bit of work to configure, but you only have to do it once – and once it’s done it’s like magic. Any time I get a bug notification email, the link opens my bug tracking app, not my main web browser. If the bug tracking app isn’t open…Browser Fairy will open it so I don’t have to keep 10 things open all the time.

Browser Fairy is $4.99 in the App Store – with Fluid apps they’re a super-duper productivity enhancing duo.

Why was Wall Street surprised by Apple’s performance?.

I ran into trouble when I pushed my work up to my Dreamhost account. The application was failing silently. Running silex.phar on the command line resulted in meaningless errors.

After a fair bit of Duck-Duck-Go-ing (Duck-Duck-Goosing? Quacking?) I found squat. After dumping out a PHP info page I realized that Dreamhost is using Suhosin (which is a good thing). This was the culprit.

The Silex documentation provides configuration examples showing how to configure PHP and Suhosin to work with the Silex framework. Fortunately, Dreamhost lets you override the system default PHP.ini with your own.

In order to this work you should have PHP 5.3.x FastCGI enabled for your domain. Leave “Extra web security” on so you feel snuggly and safe in your bed at night.

Make sure your login account (your FTP user) has shell access enabled – this configuration cannot be done without shell access.

Follow the instructions on the Dreamhost support wiki for replacing the system php.ini. If you don’t know what any of those instructions mean, this is not for you. Contact support and ask nicely for them to do it for you.

Once you have a shiny new ini file (the file will be named “phpini”) look for the following line:

;;; VALUES BELOW WILL OVERRIDE ANY SET ABOVE! 

Above this line are system defaults. Leave them be. Below this line you will add your customizations.

Add the following recommended configurations from the Silex documentation:

detect_unicode = Off
phar.readonly = Off
phar.require_hash = Off
suhosin.executor.include.whitelist = phar 

And then add the following to ensure that the PHAR extension is loaded:

extension=phar.so 

Then follow the Dreamhost instructions for forcing PHP to reload the configuration – or go make some coffee and come back in 15 minutes or so. Dreamhost will eventually reload the configs automatically.

Silex should now run fine, both in the browser and on the command line. Of course your mileage may vary.

To produce the needed base64 encoded images, I’ve been relying on a tiny little command line script to encode the image and spit out the results. While this works, it’s not particularly convenient and it’s not something I can easily share with other developers and the graphic designers on my team.

So over the weekend I built bGrounder.

bGrounder lets you upload images and convert them into CSS rules and HTML image tags with images embedded directly with data URIs. If you’re using a modern browser that isn’t Internet Explorer, you can click and drag images from your desktop right into the uploader. In all browsers you can add many images via the ‘Add images’ button (HTML5 browsers allow you to select multiple images at once).

Process each image individually or do them all at once. The resulting code appears in the text boxes below the uploader. The CSS rules specify the encoded image as a background image, using a class name derived from the file name of the image. The HTML output is a simple IMG tag with width and height set. The IMG tag is probably less useful over all – generally inline images are part of actual content of the page and you probably don’t want to completely ignore older browsers. But maybe you do. Maybe that’s just how you roll. Additionally if you reuse the same IMG tag with embedded image data, you get no benefit from caching…the browser has no way to know that two embedded images are the same (whereas a single CSS sheet is loaded once).

Share and enjoy.

Technical stuffs

bGrounder gave me a chance to play with the Silex PHP “micro-framework”. I found it very easy to get up and running with Silex, surprisingly so. I rather liked the simplicity and minimalism of defining function closures which respond to URL patterns and HTTP methods. Very tidy. My main application file was only 50 lines long, including comments and generous whitespace. (this doesn’t include the Silex library itself, or the image processing classes I wrote, but still. Short.)

This also gave me the chance to work with this jQuery File Upload widget. This set of jQuery plugins enhances an existing file input to allow for multiple uploads in old browser, creates a rich UI with progress bars, and can even support cross domain uploading. It also ships with a number of server-side implementations to help you get started. Perhaps somewhat ironically, this was more complex than the PHP framework. Once I got my head around how it worked though, it was fairly easy to customize the UI and use my own server-side upload handler.

The gist is that Adobe’s magazine app publishing platform (as well as other’s) creates a magazine by wrapping up a big stack of PNG image files in a thin interactivity layer. On the new iPad, these images will be too small to be legible. I hinted at this problem when I reviewed Vanity Fair’s iPad edition. Today each “magazine” is an enormous file (200MB to 400MB) with text that can’t be enlarged, selected, copied, exported, or read aloud by accessibility software. In order for this publishing format to work on high resolution displays, the images will have to be much higher resolution – and therefore much larger in file size. Otherwise the text will be blurry and hard to read. If you increase the size of the images making up each page, you increase the overall file size of each magazine. These things are already too big to store. I never keep more than an issue or two on my iPad. And of course, download times will increase as well.

I already find these magazines hard to read. Even my 37 year old web nerd eyes find the text in these magazines (on the original iPad) to be too blurry. Compared to iBooks, the Kindle App, or just any old web page in Safari, they look terrible (at least for reading). I came to the same conclusion that David did; they should have been using web technologies all along.

Vanity Fair has a decent web site already and they obviously have a CMS supporting it. Why not create a tablet optimized version of the site with the same content as the magazine then make that site an add-on to an existing subscription or create a partial pay-wall? That web content could be wrapped in an app and cached for offline use. Most graphics (borders, boxes, shapes, etc) could be delivered as tiny SVGs, photos could be delivered as hi-res JPGs. The end result would be much smaller than what they deliver now, but far more readable. It’s possible that they might have to sacrifice some fine layout control…but the result would be reasonably future proof content.

Vanity Fair and Conde Naste have already produced and killed one version of a magazine app. The current one is about to be obsoleted, as is all the content they’ve already produced for it. Why keep hitching their wagon to Adobe’s lame last century mentality mule?

• A Retina Display Reckoning for Magazine Publishers
• Via Shawn Blanc

I’ve been avoiding this technique for a while – in my professional work I’ve had to (and chosen to) support legacy browsers (koff IE 6) but perhaps it’s time.

Unfortunately, to accomplish this Path was uploading your entire address book from your phone to their servers without your explicit consent or knowledge. Since this has come to light, Path has apologized (which is great) and updated their app so this behavior doesn’t happen without explicit user consent.

We were trained for this moment

For years now sites like Twitter, Facebook, LinkedIn, et al have been asking people to login to their email service (gmail, yahoo, or whatever) and allow contact information to be extracted and used to pre-populate your account with contacts (e.g. Find friends, find followers, find people in your network).

I always considered this action to be shady. How could I know they weren’t keeping that information and selling it to spammers? How could I know they weren’t, say, reading my email? Most people, though, thought it was an acceptable trade off. Their new account would be up and running quickly, and they wouldn’t have to manually enter contacts or track down their friends.

Even though I find this “feature” to be a bit sketchy, at least it was an explicit request, followed by an explicit login. It’s safe to assume that the user knows what he’s intending when he clicks the “Import your gmail contacts” button.

People have become accustomed to this behavior, having used it for years now, so when you launch Path for the first time and all your friends are already there…it’s easy to assume you must have logged in somehow, or, more likely, you don’t even care how all your contacts showed up.

Are you surprised by this?

Path claims that they were only using address book data to help users find each other on their service. I believe this is true, today. The problem of course is what happens to that data tomorrow. If Path gets bought out, what do the new owners do with that data? They have no explicit contract with the users of the application, so are they legally bound in any way? Probably not.

All social networks1 rely on vast amounts of demographic data as the basis of their business model. Facebook and Google use this demographic data to sell advertising. Twitter uses it to sell promoted tweets and trends. This is why there are no well known, for-pay, public, social networks (that aren’t porn)2.

After all the privacy problems discovered with Facebook and Google you simply must regard any and all social networking applications to be systems designed to extract your personal data and sell it. You are “paid” in return with a service you hopefully find fun or useful3.

DuckDuckGo’s best two features are:

1. It has no features
2. It respects your online privacy

Well. It’s not true that it has no features. DuckDuckGo just focuses entirely on web search. It doesn’t litter the page with garbage-ey social features and doesn’t filter your search results based upon your past search history.

And sure they have lots of little goodies and widgets but mostly it’s just a nice clean search engine with no BS.

They include a ‘behind the scenes’ page where they discuss some of the technologies used. It’s fairly interesting but includes some dumb marketing language:

It was a daunting task: get this code into a browser while maintaining the unique personality and incredible quality that gamers are accustomed to. To accomplish this, we bet on JavaScript.

Safe bet. When I have to choose between JavaScript or JavaScript I also bet on JavaScript.

The Colorzilla gradient editor is a visual gradient editor like you might find in Photoshop or Pixelmator. Once you’ve specified your gradient, you see an HTML preview plus CSS style rules to create that gradient in modern browsers, and a reasonable approximation using IE’s filter syntax.

Click and draggy

A new checkbox toggles IE 9 support. Selecting this option includes a base64 encoded SVG background image along with the rest of the browser gradient definitions. In order for this to work properly it is necessary to include an IE9 specific style rule (in a conditional stylesheet) which disables the filter definition for legacy versions of IE. An example of this style rule is included in the application.

Click the box for IE 9 support

I have to confess that I’ve been using this tool in lieu of my own script. There are a few reasons.

Pros

Having the SVG definition pre-built and available right in-line removes dependencies on JavaScript and means there’s no extra HTC file to keep up with. Additionally, since there’s no scripting involved, there’s no possibility of collisions with your any scripting in your application.

If one wanted, one could just use the SVG definition and remove all the other gradient definitions (except of course the filter rule). Any browser which supports CSS3 gradients will support an SVG background image. This would let you clean out redundant, browser specific style rules in all your gradient styles.

This technique is reasonably future proof, as it uses standard HTML and a standard SVG. If IE 10 fails to support gradients, this technique will still work.

I have no idea if my HTC script will work on the new mobile IE on Windows Phone 7and (hypothetically) Windows 8. (If someone wants to give me a free Windows Phone, I’ll be happy to test.)

Cons

If you’re using CSS3 gradient definitions, it’s technically possible to tweak or edit them “by hand” without using a special tool. To make any changes to an encoded SVG image you’ll either have to decode, edit, and re-encode or you’ll have to create a new image from scratch. If you’re using a tool like the Colorzilla gradient editor, this isn’t a huge problem – but it’s still an extra step.

Since the SVG gradient is encoded inline in the main stylesheet, all browsers must download this image whether they use it or not. So in a way you’re punishing all users for IE 9’s sins. My dynamic solution targets IE 9 specifically.

It is possible that one day this tool will simply disappear. If that happens, then designers and developers might be scrambling for a replacement.

I recommend

I recommend using Colorzilla’s tool over my script for supporting IE 9 gradients. In practice, I find it’s simply far easier for me to just define a gradient and copy/paste the generated CSS into mine, and follow up with a little clean up once the design is settled.

I’m happy with my script, and there may be cases where it’s preferred (smaller download sizes, targeting only modern desktop browsers, etc) but I think the Pros of using Colorzilla’s tool outweigh the Cons.