Among the many awesome things we saw there was this amazing audio monstrosity...

This is the Paradiso Modular Synthesizer, a massive assembly of electronics that was started in 1973 by Joe Paradiso, an associate professor at MIT's Media Lab, and finished in the 1980's.

He explains it himself in this video:

Occasionally, its output is streamed live, and they've even authored a web interface that allows people to play it!

There's a .zip with pre-sized desktop wallpaper images, covering a large range of screen sizes including retina iPhone and iPad, located here. Enjoy!

The nature of the event (obstacles, mud, water, barbed wire, junkyard metal, etc) makes it a perfect opportunity to "retire" a pair of running shoes, but all is not lost, because even though they might be ruined for the purpose of running, there's still a lot of practical use remaining. One of the cooler aspects of the event is participation in the Green Sneakers program, which aims to bring these shoes back from the brink of destruction, clean them up, and distribute them to people around the world.

Among the photos I took today was this shot of one small section of the mountains of piled up used shoes:

Part of the donation process involved tying your old shoes together so that they didn't get lost, so each shoe has a sibling not too far away.

There's a .zip with pre-sized desktop wallpaper images, covering a large range of screen sizes, located here. Enjoy!

Here's a resized crop of the entire image:

Impressive on its own, but here's a 100% crop of the very middle of the image, taken from the full size 14540px by 14540px image:

To put things in perspective, the image directly above represents a tiny 15px by 15px region from the image above it. Pretty inspiring.

Upon first view, the radial nature of the full image reminded me of the e8 group that I made wallpaper out of in a previous post. Creating desktop wallpaper for myself is something I do pretty regularly, so I'm always excited to have a high resolution master asset to work from. Normally, this stuff never leaves my machine, but I figured I'd share this one with whoever wants it:

I've done some processing on the original image to deepen the blacks, taken some samples from the e8 group rendering that I used previously, and added a 360 degree radial hue shift to keep with the circular theme.

To download a package with many different resolutions and crops, click here.

(there's also a bonus for my fellow 27" and 30" monitor people)

Fluid is an OSX application that allows you to create individual applications that encapsulate a browser that defaults to a single URL. They run in their own memory space, can be hidden, shown and Cmd-Tab'd to like any other native application, launched from the Dock, etc.

Creating an app out of a URL is easy in Fluid, but the way that Amazon.com handles authentication requires a quick, simple preference edit in order to properly log in and get cookied.

To get started, download Fluid.

Once you've installed it, run it and use the following URL:

https://www.amazon.com/gp/dmusic/mp3/player

Enter a name for the application. I used "Amazon CloudPlayer."

Click on "Create" and wait while the application is prepared. When it's finished, an option to run it is presented. This didn't work for me, so I located the new app in the Applications folder and launched it.

Because this browser isn't cooked to Amazon, you're presented with a login form, but attempts to execute the login will result in a page being opened in your default browser, preventing the Fluid-encapsulated browser from receiving the required cookie.

Luckily, this is easily fixed. In the Preferences of the Amazon CloudPlayer app, click on the Advanced icon:

Then, select "Allow browsing to any URL":

Try the login again, and it should work fine.

For bonus points, familiarize yourself with Fluid's plugin architecture and engineer a way for the standard media buttons on the keyboard to be hooked into the controls inside the player - I would, but I'm slammed : )

nye.andylemay.com/js

Don't be strangers!

The correct MIME type for .svg assets it:

image/svg+xml

More information about MIME types and server configuration is available here.

In researching this stuff, I discovered that the above image, which sits on the Wikipedia page about the E8 Lie Group, was rendered from an SVG asset. Having recently purchased a 27" (2560x1440) iMac for iOS development, I'm aware of the severe lack of properly sized desktop wallpaper for its enormous screen. A bell dinged somewhere in the distance, and I downloaded the SVG and started playing around with it, and now I've got some new desktops:

And so do you! Grab a .zip for your target resolution from the sizes below:

• 320x480 (iPhone 3-)
• 640x960 (iPhone 4+)
• 768x1024 (iPad)
• 1280x800
• 1440x900
• 1680x1050
• 1920x1080
• 1920x1200
• 2560x1440

The article details a series of perceived pain points that normally occur in the handoff between designers and developers. While there were a couple of valid points, I feel like this article missed the mark, and squandered a high-visibility opportunity to establish a constructive, productive dialog between people on both sides of the fence.

A point by point reaction follows:

Aesthetic decisions are part of a designer's job, and part of any decent developer's job is to execute designs with pragmatism and skill. Snarky comments like this do nothing to facilitate a designer/developer discourse that is essential to smooth project workflow. Also, I find it odd that a developer would discourage the use of practices that have become so common and vetted that they are a key part of forthcoming standards.

Using a design scaffold is no different than using a development scaffold, of which there are many. How the designer initiates his or her design project is irrelevant to the developer. The size of the PSD is meaningless (up to about 1.5GB) unless you’re trying to chop it up on very old hardware. Complaining about a 100MB PSD is something we used to do in the 90's.

The decision to use sIFR (or Cufon, or @font-face, or any other solution) isn't made by the designer, it's made by the developer. If the designer is using a custom font for headlines or body copy, and that presents a developmental problem (due to licensing, technology, etc) then an alarm should be raised by the developer before the development process even begins. In an ideal situation, developers get a chance to look at creative collateral before it's presented to the client, which provides an opportunity to prevent a lot of potential problems from making their way downstream.

This is a valid point, but any seasoned developer should have grown the habit of making margins and padding consistent when there is a slight difference in the creative. I always make it a point to let the designer know what I changed, and I’m usually thanked for it.

Telling designers how to design is anti-innovative and, to be honest, it comes off as whining. The comment about text wrapping around images is valid, but only a print designer with zero interactive experience would attempt such a layout. If this is the situation in a brick-and-mortar interactive shop, then there are much more serious problems at hand.

The decision to use or not use a modal window should fall in the realm of IA/UX, not design. If the designer is the individual that is determining these types of structural/experiential details, then there's a problem with process.

In what sort of workflow does a designer get to decide whether or not a site has Facebook Connect functionality? These are business decisions that should be made before the design process begins. They require input from people at all levels of the process. Adding a "Like" button, however, is as easy as cutting and pasting a single line of code. Not really something a developer can complain about.

This is a semi-relevant gripe, but the developer should have a set of comps that are used for master reference (the client wasn't sent a set of Photoshop files to approve). Elements in these comps should be contained in layer groups that are sensibly named. A better approach is to simply make a rule that all layers in the delivered PSD contain content relevant to the project, and any layers that contained experiments or discarded stuff will be deleted from the PSD before it's sent to the developer. This has been a problem at every place I've ever worked, and it's probably the most common cause of frustration and wasted time during the designer/developer handoff.

It's much easier to assume that all buttons will at least require an over state, and should probably require down and up states as well.

As a developer, part of your job is to be tuned in to trends and advances in your field. Your role is ultimately to build things and solve problems by determining what is possible and what is not. Being presented with a new tool or methodology is something that should be celebrated, if only for its potential to enhance your own skillset. Any term or process that you're hearing about for the first time deserves immediate research and consideration.

Once again, this should be an IA/UX related decision, not a designer's. Also, on the topic of carousels, they happen to be a fairly efficient way to navigate and present visual content, which is part of the reason that Apple is including prefab carousel functionality as part of the iAd JS framework. These types of controls have become so popularized in recent years that they should be able to be constructed from scratch, if need be, by even a mid-level web developer.

Placeholder copy is better than no copy at all, and often times the copy is being developed in parallel to the design, and often times isn't finished until the development cycle (due to revisions, rounds with legal, etc). This isn't a legitimate gripe. The comment about copy length is valid, but this is also an IA thing, not so much a designer thing.

I don't get this comment. Merging layers is a normal part of Photoshop workflow. They all have to be merged at some point anyway. If a designer has the prescience to accurately flatten elements into single layers, more power to them. If they flatten too much, then request an unflattened asset. Most designers only overflatten something ONE time without a backup before learning that lesson.

Due to the lack of usable version control architecture on the design side of the fence, I've seen plenty of creative asset naming schemes. Ultimately though, whatever system a designer uses to keep track of their assets doesn't concern me. Just point me to the file that I'm supposed to develop. If it's a folder that has a bunch of nebulously named files in it, I'll assume that the most recently saved file is the one I should be working from. If it's not, then a discussion is needed. These situations are rarely epidemic, and almost always solved after a single occurrence.

Even the most simple workflow will either prevent this from happening, or gracefully handle last minute stuff like this. This is the kind of complaint that I can really only identify with in the context of doing freelance work for people who know nothing about the interactive medium. Also, anyone who has done this for more than a year or two should know that projects without last minute edits are rare. The PMs who really have their shit together are building it into their schedules from day 1, because it's basically guaranteed.

This might be the only fully valid gripe in the entire article. A PSD with no semblance of organization or naming can exponentially increase the amount of time it takes for development. In my experience, this is the #1 thing that wastes time in the development cycle.

This stuff falls to IA/UX, not design. These are all things that should be tagged in scope documentation. If the designer isn't including stuff that's in the docs, then get a new designer.

This is a completely valid gripe, but it's a side effect of agency process, not an individual designer. Smart designers bounce their ideas off of developers, and smart agencies make that a part of the creative process.

The debate about whether designers should use bug tracking software isn't winnable. It's arguably the most horribly designed software out there, and the signal to noise ratio for a designer will usually be almost intolerable. Having someone make changes over your shoulder is a tossup. It's either awesome to have a designer that's willing to do that on a tight schedule, or it sucks because it prevents you from checking Facebook or tweeting about how awesome you are.

The more a designer knows about the capabilities of the medium that they're designing for (be it print, web, whatever) the better they will be as a designer, no doubt. I don't think it's a designer's job to know about browser inconsistencies any more than it is a developer's job to know about brand standards or, god forbid, basic typography. With that said, the best of each side are always curious enough to learn about this stuff on their own.

Perhaps most of these issues can be solved without involving designers OR developers. Let's have a conversation with HR instead.