Key Ingredient iPad App Now Available!
August 4th, 2010
This did not happen.
Transmogrify’s first iPad app is now available in the App Store. Special thanks to Key Ingredient for being an awesome partner in this endeavor.
R5 Productions iPhone App Update
June 24th, 2010
Version 1.2 of the R5 Productions iPhone app is now in the App Store.
Get it now!
New features:
What the iPad Owes to Flash
May 11th, 2010
For all of the internet ruckus regarding Apple and Adobe — both official and unofficial — I haven’t seen anything written about the positive influence Flash has had on user experience design (and how that influence has affected the iPad). Though it’s often written off as an enabler of awful design and annoying splash screens, today’s haptic interfaces owe a lot more to Flash than most would be willing to admit.
As I was browsing the web for creative ways of handling navigation for an in-the-works iPad application, it struck me that there really is no model for interaction on the iPad. Some would claim that this lack of UI ancestry is because Apple is magically revolutionizing the way software can be designed, and that we’re now free to pursue our wildest user interface dreams. While I don’t disagree that the iPad provides a wonderful user experience, I do think that some of the design principles iPad app designers are currently using have been around for quite a while, and are readily found in Flash sites.
Because of the (admittedly warranted) bad name that Flash has for a variety of reasons, people are apt to overlook some of the very nice things that it’s capable of when in the right hands. As a result, they simply don’t look for influence within the medium. Apple seems to enjoy fanning the flame of contempt for Flash that web standards advocates started years ago, and coupled with the release of their “hot new” platform that is so rabidly and publicly anti-Flash, the avoidance of Flash design has no real hope of turning around. I want to be clear, though, that I’m not denying that Flash’s time is up, or that its usefulness — short of video — isn’t long since expired.
Apple’s official beef with Flash and the echo chamber that has ensued is doing something that I think could hurt the design of iPad applications, at least in the short term. This constant trash-talk from the loyalists of a company that designers consider to be the epitome of hip is encouraging those same designers to ignore some pitfalls of design that good Flash designers have already handled with finesse. Apple’s notoriously hard-line approach to protecting its intellectual property is doing nothing to help application designers develop a community of positive influence. Before the iPad was released, the only way a development shop could get their hands on one was to black out room to house it and then secure it to an immovable object. So for those of us who started working on iPad apps before the device was available, where were we to go for design influence? Where I arrived was Flash.
HTML (with some JavaScript influence) has come a long way — and I believe that it will eclipse even native device applications in the future — but experimentation with the medium is only recently gaining some momentum. Flash, however, has been a commonly used platform for unique user experiences, both good and bad, for years. While browsing recently for navigation design, I stumbled on some very nice examples of interaction using Flash. Although some of these sites commit the cardinal sins that have earned Flash its awful reputation, what they do well is find fun ways to deal with the problems that also plague iPad designers; non-linear information and navigation design, touch-like interaction (dragging, swiping, etc.), faux realism in UI elements, and animation.
I do know that time will fix this problem, and that after a few generations of iPad applications there will be a suitable ecosystem for sharing and developing influence within the iPad design community. But I’m worried that because of the constant barrage of anti-Flash writing, some perfectly acceptable — and in many cases quite good — sources of inspiration are going ignored. I’m in no way defending Flash as a platform to developers, but merely admitting that Flash is not all bad, in much the same way that iPad and iPhone applications are not all good, and that there is some value in good Flash design that could positively influence designers.
RestFB now supports the Facebook Graph API
May 1st, 2010
I’m pleased to announce that RestFB 1.5 has been released and includes support for the new Facebook Graph API. If you’re a Java developer and are interested in trying out the latest and greatest from Facebook, I recommend checking this out. The Graph API is really easy to use and fun to work with – you can do lots of neat things with all that data! I welcome any feedback or bug reports you might have – come on over to the RestFB Google Group and let the community know your thoughts.
Transmogrify on Facebook
April 30th, 2010
We’ve finally gotten around to creating a Facebook group for xmog. “Like” us if you’d like!
Transmogrify: Now on Facebook
To Honor Mr. Tufte…
March 9th, 2010
…on his recent appointment by President Obama, I would like to post this:
Plotting Fear and Rage in Wolves
As a side: Tufte is doing another one-day course in Philadelphia next week. I’m going, is anyone else?
Google is A/B Testing
February 4th, 2010
Just wanted to post screenshots of what I was just shown while a-Googlin’. In my opinion it’s very nice, but it may just be because there are no ads.
With sidebar options collapsed.
With search filters expanded.
With search tools expanded.
And check out the newly polished Google logo/paging:
New logo/paging.
WordPress Permalinks 404 when Running in OS X
February 4th, 2010
I’m a designer here at Transmogrify (read: not a developer) and therefore close to none of what I’m about to write makes sense to me. I have, however, just solved a problem that’s been giving me trouble for a few hours now, and wanted to share it.
I installed WordPress on my MacBook Pro so that I could do a build-out of a site without needing to have hosting set up yet. Luckily, (Snow) Leopard has Apache and PHP support preinstalled, and the WordPress setup went off without a hitch (which was pretty impressive).
PHP has to be put into this folder by default for it to run on your machine: /Library/WebServer/Documents/
I’m sure there’s some way to change that, but it’s over my head. You can put things into subfolders in that folder though, and my install of WordPress is running from /Library/WebServer/Documents/wordpress/ (this is important to note for later). To view the site, I just need to go to http://localhost/wordpress/ in a browser.
I cleared my theme and started building the design from scratch when I remembered that I hadn’t yet set up “pretty” permalinks. The site is going to be page driven, with no posts, so I wanted to use this approach for links:
Which would make links that (eventually) look like this: www.website.com/contact.
After a little searching, I found some pointers from others with similar problems and followed their instructions. What I did was as follows:
1. Created an .htaccess file and dropped it into the main WordPress folder. I made that file in TextEdit, and saved it to /Library/WebServer/Documents/wordpress/. In order to see that file though, I needed to show hidden files in the Finder. To do that, I opened the Terminal and ran this:
defaults write com.apple.Finder AppleShowAllFiles TRUE
and then restarted the Finder in Terminal:
KillAll Finder
(Note: To hide hidden files again, just run this again but change TRUE to FALSE.)
2. I set permissions on the .htaccess so that it’s writable by WordPress. The easiest way to do this is to get info (command + i) on the newly created and unhidden .htaccess file in Finder, and change all of the settings under Sharing & Permissions to “Read & Write.” There’s also a nice tool for changing file permissions in a more FTP client-like way, called BatChmod. The most “natural” way is to do this via the Terminal, but I’m more of a GUI type of person. Here’s what the Get Info screen looks like:
After all of that, I thought I was good. I went to the Permalinks settings in the WordPress Admin and set up my custom URLs. Unfortunately, any time I changed the Permalink settings from the default setting to anything else, all of my links would change but the pages would 404. This is where the real fun started.
More searching ensued, and I stumbled onto the idea that httpd.conf (an Apache configuration file) needed to be edited to allow your .htaccess to rewrite URLs. I found this information on WordPress forum threads and blog posts like this, this, and this. Though some of these suggestions may help you solve your problems, I was still faced with a dreaded 404 error on every page.
Those posts all pointed me to /private/etc/apache2/httpd.conf, but what I found is that the real file that needed to be fixed was here: /private/etc/apache2/users/myusername.conf. Here’s what I needed to do:
1. Opened /private/etc/apache2/myusername.conf in a text editor.
It looked like this:
3. Copied that chunk of code and pasted it again below it. So it looks like this:
If you don’t have it already, you will also need to add “FollowSymlinks” to the Options for each entry. (Thanks Jozz!)
4. Changed the Directory and the AllowOverride settings on the second entry so that all together it looked like this:
Remember when I said the location of your WordPress install was important? This is the directory you need to enter here. The problem wasn’t that the .htaccess wasn’t creating the right links, it was that Apache wasn’t being pointed to that directory to find the .htaccess file. This was the key to getting it all working.
5. Restarted Apache. The easiest way to do that is by going into the Sharing preference pane and turning “Web Sharing” off and turning it back on again.
And finally, I had nice URLs!
It’s probably a good idea to hide all of those hidden files again at this point.
Announcing RestFB
February 2nd, 2010
We’re proud to announce the 1.0 release of RestFB, a simple and flexible Facebook REST API client written in Java.
This library makes it easy to communicate with the Facebook API and, as outlined on the website, provides a minimal yet powerful and extensible interface on which to build your own Facebook applications.
So, if you’re a Java developer, give it a try and see what you think. We’d love to hear any feedback. Don’t forget to log any bug or enhancement requests in our issue tracker!
How long can a Facebook status update be?
January 18th, 2010
We needed to know for sure for an app we’re writing so we tested it the old fashioned-way (stuffing the input field until an error message popped up). The limit, it seems, is 420 characters – very funny, guys.
Subscribe
